Zum Hauptinhalt springen

Database-per-Service / Database-per-Module

Einleitung​

Database-per-Service bedeutet:

Jede fachliche Einheit besitzt ihre Daten –
und nur sie darf sie direkt verändern.

Das Muster stärkt Autonomie und reduziert Kopplung über gemeinsame Datenbanken.

Es ist eines der zentralen Prinzipien verteilter Architekturen –
und eines der am häufigsten verletzten.

Einordnung

Database-per-Service ist ein Meso-Pattern für Datenhoheit.

Es betrifft:

  • Microservices
  • Self-Contained Systems
  • Modular Monoliths (Database-per-Module)

Es beschreibt Ownership und Zugriffsregeln, nicht zwingend Infrastruktur.

Grundprinzip

Kernaussage:

  • Keine direkte Fremdtabellen-Zugriffe
  • Keine Cross-Service-Joins
  • Integration über APIs oder Events

Wichtige Klarstellung

Database-per-Service bedeutet nicht zwingend:

  • separate physische Datenbank-Server

Es bedeutet:

  • logische Isolation
  • getrennte Schemas oder Instanzen
  • strikt kontrollierte Zugriffsrechte

Charakteristika

1️⃣ Datenhoheit​

Ein Service:

  • definiert sein Schema
  • kontrolliert Migrationen
  • verantwortet Datenqualität

Andere Services:

  • konsumieren über API oder Events
  • lesen nicht direkt Tabellen

2️⃣ Keine implizite Kopplung​

Direkter DB-Zugriff erzeugt:

  • versteckte Abhängigkeiten
  • Release-Kopplung
  • unkontrollierte Seiteneffekte

Shared Database ist oft der Kern eines Distributed Monolith.

3️⃣ Konsistenz über Prozesse​

Globale ACID-Transaktionen entfallen.

Stattdessen:

  • Saga
  • Eventual Consistency
  • Outbox Pattern
  • Idempotente Consumer

4️⃣ Reporting-Strategie erforderlich​

Cross-Domain-Queries brauchen:

  • Data Projections
  • Event-getriebene Read Stores
  • ETL/Analytics Pipelines

Reporting darf nicht über Cross-Table-Joins erfolgen.

Vorteile

  • Klare Ownership
  • Unabhängige Schema-Evolution
  • Entkoppelte Deployments
  • Bessere Sicherheit durch isolierte Zugriffsrechte

Risiken / typische Fallstricke

1️⃣ Versteckte DB-Zugriffe​

„Nur mal schnell lesen“ führt zu:

  • Release-Kopplung
  • Chaos

2️⃣ Reporting-Komplexität​

Cross-Domain-Reports werden aufwendiger.

3️⃣ Datenredundanz​

Replikation und Projektionen erzeugen:

  • Speicheraufwand
  • Synchronisationslogik

4️⃣ Fehlende Prozess-Strategie​

Ohne Saga/Outbox wird Konsistenz fragil.

Wann sinnvoll?

  • Klare Domänengrenzen
  • Autonome Teams
  • Unabhängige Releases wichtig
  • Eventual Consistency akzeptiert

Wann problematisch?

  • Stark transaktionale, fachübergreifende Prozesse
  • Globale Echtzeit-Reports zwingend
  • Fehlende Plattform-Reife
  • Keine Event- oder Integrationsstrategie

Modular Monolith Variante

Im modularen Monolith:

  • eine physische DB
  • aber modulweise logische Isolation
  • kein direkter Tabellenzugriff über Modulgrenzen

→ Database-per-Module

Vergleich

AnsatzDatenhoheitKopplungKomplexität
Shared DatabaseNiedrigHochNiedrig (anfangs)
Database-per-ModuleMittelMittelMittel
Database-per-ServiceHochNiedrigHoch

Strategische Perspektive

Database-per-Service erhöht:

  • Autonomie
  • Evolvierbarkeit
  • Sicherheit

Es erhöht aber auch:

  • Integrationskomplexität
  • Bedarf an Event-Architektur
  • Reporting-Aufwand

Es ist ein Autonomie-Instrument – kein Performance-Pattern.

Fazit

Database-per-Service schützt Service-Grenzen.

Ohne dieses Prinzip entsteht:

kein verteiltes System, sondern ein verteilter Monolith.

Mit diesem Prinzip entsteht:

  • echte Datenhoheit
  • echte Entkopplung
  • echte organisatorische Autonomie.