Data Governance für Microservices: Wer besitzt welche Daten in einer verteilten Architektur?

Daten-Chaos verhindern: Governance in der Welt der Microservices

Der Wechsel von einem Monolithen zu Microservices bringt viele Vorteile, schafft aber eine gewaltige neue Herausforderung: Die Datenhaltung. In einem Monolithen gibt es meist eine zentrale Datenbank (“Single Source of Truth”). In einer Microservice-Architektur besitzt jeder Service seine eigenen Daten. Ohne klare Regeln (Data Governance) führt das schnell zu redundanten, widersprüchlichen oder verwaisten Datensätzen – ein Albtraum für die Konsistenz und die DSGVO-Compliance. In diesem Beitrag zeige ich Ihnen, wie ich Data Governance in verteilten Systemen strukturiere.

1. Das Prinzip des Data Ownership

Governance beginnt bei der Verantwortung. Jeder Datensatz muss genau einem “Owner-Service” zugeordnet sein.

• Single Source of Truth: Nur der Owner-Service darf Schreibzugriffe auf diese Daten ausführen. Alle anderen Services dürfen die Daten nur über die API des Owners abfragen oder (bei hoher Last) eine schreibgeschützte Kopie (Read Model) vorhalten.
• Beispiel: Ein CustomerService besitzt die Stammdaten. Der OrderService darf die Lieferadresse zwar anzeigen, muss sie aber bei Änderungen beim CustomerService anfordern.

2. Datenkonsistenz: Eventual Consistency statt 2PC

In verteilten Systemen sind klassische Datenbank-Transaktionen über Servicegrenzen hinweg (Two-Phase Commit) langsam und fehleranfällig.

• Event-Driven Architecture: Ich nutze Events (z.B. via Redis Pub/Sub oder Kafka), um Änderungen zu propagieren. Wenn sich eine Adresse im CustomerService ändert, wird ein AddressChanged-Event gefeuert.
• Saga-Pattern: Für komplexe Prozesse, die mehrere Services betreffen (z.B. eine Bestellung), implementiere ich Sagas, um bei Fehlern automatisierte Kompensations-Aktionen (Rollbacks auf Logik-Ebene) auszuführen.

3. API-First und Schema-Registry

Daten sind nur so gut wie ihre Definition.

• Contract Testing: Ich nutze Tools wie Pact, um sicherzustellen, dass Änderungen an einem Datenschema im Owner-Service nicht unbemerkt die Consumer-Services “kaputt machen”.
• Protobuf/gRPC: Für die interne Kommunikation setze ich oft auf Protocol Buffers. Die Schemata sind dort explizit definiert und versioniert, was die Governance massiv erleichtert.

4. DSGVO und das “Recht auf Vergessen”

In einer verteilten Architektur ist das Löschen eines Nutzers eine technische Herausforderung.

• Distributed Delete: Der Owner-Service muss sicherstellen, dass bei einer Löschanfrage alle anderen Services, die Kopien oder verknüpfte Daten halten, informiert werden.
• Audit Trail: Wir dokumentieren zentral, welcher Service welche Datenkategorien von welchem Owner bezieht. Dies ist die Basis für das Verarbeitungsverzeichnis.

Fazit: Governance ist das Fundament der Skalierung

Microservices ohne Data Governance führen unweigerlich in technische Schulden und rechtliche Risiken. Indem wir klare Owner definieren, auf asynchrone Kommunikation setzen und Verträge zwischen Services strikt einhalten, schaffen wir eine Architektur, die nicht nur technisch skaliert, sondern auch fachlich sauber bleibt.

Haben Sie den Überblick über Ihre Datenflüsse in der Microservice-Landschaft verloren?
Ich helfe Ihnen bei der Definition von Daten-Strategien und der technischen Umsetzung von Governance-Mechanismen. Kontaktieren Sie mich für ein Architektur-Review.