Wie wird die Datenkonsistenz in einer Microservices-Architektur mittels Saga Pattern (Orchestration vs. Choreography) sichergestellt?

Das Saga Pattern stellt die Datenkonsistenz in verteilten Systemen durch die Implementierung von Eventual Consistency sicher. Da klassische ACID-Transaktionen über Servicegrenzen hinweg zu Performance-Einbußen und Deadlocks führen, unterteilt eine Saga einen Geschäftsprozess in eine Sequenz lokaler Transaktionen. Jede lokale Transaktion aktualisiert die eigene Datenbank und löst über ein Event oder eine Nachricht die nächste Transaktion im Prozess aus. Tritt in einem Schritt ein Fehler auf, löst die Saga kompensierende Transaktionen aus, welche die Auswirkungen der bereits erfolgreich abgeschlossenen vorherigen Schritte rückgängig machen.

Wir unterscheiden dabei zwei primäre Implementierungsansätze:

Bei der Choreografie kommunizieren die Services über einen Message Broker. Service A schließt seine Aufgabe ab und publiziert ein Event. Service B reagiert darauf. Schlägt Service B fehl, publiziert er ein Fehler-Event, auf das Service A reagiert, um seine Änderung rückgängig zu machen. Dieser Ansatz ist hochskalierbar, führt jedoch bei komplexen Workflows zu einer unübersichtlichen Event-Kette.

Die Orchestrierung nutzt eine zentrale Komponente (den Orchestrator), die als State Machine fungiert. Der Orchestrator sendet Befehle an die beteiligten Services und wartet auf die Antwort. Bei einem Fehler steuert der Orchestrator explizit die notwendigen Kompensationsschritte in der korrekten Reihenfolge. Diese Logik integrieren wir oft in unsere Data Engineering Strategien, um die Datenintegrität über verschiedene Domänen hinweg zu gewährleisten.

Für Geschäftsprozesse mit mehr als drei beteiligten Services empfehlen wir die Orchestrierung, da sie die Komplexität der Fehlerbehandlung zentralisiert und die Gefahr von "Event-Spaghetti" eliminiert, was die Wartbarkeit und Überwachbarkeit des Systems signifikant erhöht.