ADR-0002: Database-per-Service (logisch getrennt, physisch eine Postgres-Instanz)

Status

Akzeptiert (2026-08-04)

Kontext

Bei Microservices ist "Database per Service" die Standardempfehlung: jeder Service besitzt seine Daten exklusiv, andere Services greifen nur ueber die API oder ueber Events zu - niemals direkt auf eine fremde Datenbank/Tabelle. Das verhindert versteckte Kopplung ueber das Datenbankschema (einer der haeufigsten Gruende, warum "Microservices" in der Praxis doch wieder zu einem verteilten Monolithen verkommen).

Die Frage ist nur: eine Postgres-Instanz pro Service (volle physische Isolation, naeher an Produktion) oder eine gemeinsame Postgres-Instanz mit einer Datenbank pro Service (weniger Infrastruktur-Overhead lokal)?

Entscheidung

Fuer die lokale Entwicklungsumgebung (infra/docker-compose.yml) nutzen wir eine Postgres- Instanz mit sechs separaten Datenbanken (catalog_db, member_db, lending_db, reservation_db, fine_db, keycloak_db), angelegt via infra/postgres/init-multiple-dbs.sh. Logisch bleibt die Trennung vollstaendig: jeder Service kennt in seiner application.yml nur seine eigene Datenbank, es gibt keine Cross-Database-Queries oder Foreign Keys ueber Datenbankgrenzen hinweg.

Im Kubernetes/Helm-Profil (infra/helm, Phase 7) bleibt dieselbe logische Trennung bestehen; dort liesse sich pro Service leicht eine eigene PostgreSQL-Ressource (z. B. via CloudNativePG-Operator) ergaenzen, um naeher an eine Produktionsarchitektur heranzukommen - das ist als Erweiterungsaufgabe im DevOps-Kapitel vermerkt.

Konsequenzen

Positiv

• Ein Container statt sechs -> schnellerer Start, weniger RAM/CPU auf Entwickler-Laptops.
• Ein pg_isready-Healthcheck statt sechs.
• Migrationswerkzeug (Flyway) pro Service bleibt trotzdem strikt auf die eigene Datenbank beschraenkt - die Trennung ist im Code, nicht nur "zufaellig durch Betriebsmodell" gegeben.

Negativ / Trade-offs

• Ein Postgres-Prozessausfall wirkt sich auf ALLE Services gleichzeitig aus (Single Point of Failure) - in Produktion inakzeptabel, hier bewusst in Kauf genommen.
• Ressourcenkonkurrenz (CPU/IO) zwischen Services ist nicht isoliert.
• Unabhaengige DB-Versions-Upgrades pro Service sind so nicht moeglich.

Alternativen erwogen

• Eine Postgres-Instanz pro Service (verworfen fuer lokale Entwicklung: 6 zusaetzliche Container nur fuer Postgres, siehe MIX-WIP-SPRING-NODE-Modular-Platform-v3 im selben Repo fuer ein Beispiel, das genau diesen Weg geht) - bleibt als moegliche Uebungsaufgabe fuer Lernende offen ("baue infra/docker-compose.yml zu 6 Postgres-Containern um").
• Shared Database (eine Datenbank, ein Schema pro Service oder gar gemeinsame Tabellen) - klar verworfen, das ist genau die Kopplung, die Database-per-Service verhindern soll.