Wie lassen sich verteilte Transaktionen in Microservices mittels des Saga-Patterns (Orchestration vs. Choreography) konsistent implementieren?

Das Saga-Pattern löst das Problem verteilter Transaktionen in Microservices, indem eine globale Transaktion in eine Sequenz lokaler Transaktionen zerlegt wird. Jede lokale Transaktion aktualisiert die eigene Datenbank und löst über ein Event oder einen Befehl die nächste Transaktion aus. Tritt ein Fehler auf, werden kompensierende Transaktionen in umgekehrter Reihenfolge ausgeführt, um die bereits abgeschlossenen Schritte rückgängig zu machen und die Eventual Consistency wiederherzustellen.

Wir unterscheiden zwei primäre Implementierungsansätze:

MerkmalChoreografieOrchestrierung
SteuerungDezentral (Event-basiert)Zentral (Orchestrator)
KopplungLose Kopplung zwischen ServicesAbhängigkeit vom zentralen Orchestrator
KomplexitätSteigt schnell bei vielen SchrittenBleibt durch zentrales Management beherrschbar
SichtbarkeitWorkflow ist implizit verteiltWorkflow ist explizit definiert
FehlerhandlingJeder Service kennt seine KompensationOrchestrator steuert Kompensation

Bei der Choreografie reagieren Services autonom auf Events. Ein "OrderCreated"-Event triggert den Payment-Service, dessen Erfolg wiederum den Shipping-Service aktiviert. Dieser Ansatz minimiert Single Points of Failure, erschwert jedoch das Monitoring und das Debugging komplexer Geschäftsprozesse, da kein einzelner Ort existiert, an dem der aktuelle Status der gesamten Saga einsehbar ist.

Die Orchestrierung nutzt eine zentrale Komponente, die den Ablauf steuert. Der Orchestrator sendet Befehle an die beteiligten Services und erwartet eine Bestätigung. Schlägt ein Schritt fehl, steuert der Orchestrator gezielt die notwendigen Kompensationslogiken. Diese Architektur ist vorteilhaft, wenn wir im Rahmen unserer IT-Consulting & Digitale Strategie komplexe Business-Logiken abbilden, die eine klare Übersicht über den Prozessstatus und eine strikte Ablaufsteuerung erfordern.

Die Wahl des Patterns hängt von der Komplexität des Workflows ab. Für einfache, lineare Abläufe mit wenigen Teilnehmern ist die Choreografie aufgrund ihrer geringen Latenz und hohen Entkopplung überlegen. Sobald jedoch mehr als vier Services involviert sind oder die Geschäftslogik häufige Änderungen erfährt, führt die Choreografie zu einem unübersichtlichen "Event-Spaghetti". In diesen Fällen empfehlen wir die Orchestrierung, da sie die Wartbarkeit massiv erhöht und die Fehleranalyse durch eine zentrale State-Machine drastisch vereinfacht.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt