Wie wird die Datenkonsistenz in einer Event-Driven Architecture mittels dem Saga-Pattern (Orchestration vs. Choreography) gewahrt?

In einer Event-Driven Architecture (EDA) wird die Datenkonsistenz über das Saga-Pattern durch eine Sequenz lokaler Transaktionen sichergestellt. Da klassische ACID-Transaktionen über Servicegrenzen hinweg nicht skalieren, setzt das Saga-Pattern auf Eventual Consistency. Jede lokale Transaktion aktualisiert die eigene Datenbank und löst ein Event aus, das die nächste Transaktion in der Kette startet. Tritt ein Fehler auf, werden kompensierende Transaktionen ausgeführt, um die bereits abgeschlossenen Schritte rückgängig zu machen und das System in einen konsistenten Zustand zurückzuführen.

Wir unterscheiden dabei zwei Ansätze zur Steuerung:

Bei der Choreografie reagiert jeder Service autonom auf Events. Ein "OrderCreated"-Event triggert den Payment-Service, dessen Erfolg wiederum den Shipping-Service aktiviert. Die Logik ist verteilt, was die Abhängigkeiten minimiert, aber das Monitoring des Gesamtprozesses erschwert.

Die Orchestrierung nutzt eine zentrale Instanz, die den Workflow steuert. Der Orchestrator sendet Befehle an die Services und erwartet Antworten. Dies vereinfacht die Fehlerbehandlung und die Überwachung des Status, führt jedoch zu einer stärkeren Abhängigkeit der Services von der zentralen Logik. Für die Implementierung solcher komplexen Datenflüsse ist ein präzises Data Engineering notwendig, um die Event-Streams und State-Machines stabil zu halten.

Für komplexe Geschäftsprozesse mit mehr als vier bis fünf beteiligten Services empfehlen wir die Orchestrierung. Die vermeintliche lose Kopplung der Choreografie schlägt bei wachsender Systemgröße in eine unübersichtliche Event-Kette um, in der die Rekonstruktion des Prozessflusses nahezu unmöglich wird. Ein zentraler Orchestrator bietet die notwendige Kontrolle und Transparenz, um Fehlerzustände schnell zu identifizieren und gezielt zu beheben.