Welche Rolle spielt die 'Saga-Logik' bei der Kompensation von fehlgeschlagenen Transaktionen in einer verteilten Architektur?

In einer verteilten Architektur ersetzen Sagas klassische ACID-Transaktionen, da ein Two-Phase-Commit (2PC) in Microservices-Umgebungen zu Performance-Einbußen und Blockaden führt. Die Saga-Logik steuert eine Sequenz von lokalen Transaktionen. Jede lokale Transaktion aktualisiert die eigene Datenbank und löst ein Ereignis aus, das die nächste Transaktion in der Kette startet.

Tritt in einem Schritt ein Fehler auf, übernimmt die Kompensationslogik. Anstatt einen globalen Rollback durchzuführen, führt die Saga für jeden bereits erfolgreich abgeschlossenen Schritt eine entsprechende Kompensationsaktion aus. Diese Aktionen sind semantische Gegenspieler der ursprünglichen Operationen (z. B. „Zahlung stornieren“ als Kompensation zu „Zahlung einziehen“).

Wir unterscheiden dabei zwei Implementierungsansätze:

MerkmalChoreografieOrchestrierung
SteuerungDezentral über EventsZentraler Saga-Orchestrator
KopplungLose KopplungAbhängigkeit vom Orchestrator
KomplexitätSteigt bei vielen SchrittenZentral verwaltet, besser überblickbar
FehlerhandlingJeder Service kennt seine KompensationOrchestrator steuert den Rücklauf

Die Wahl des Ansatzes hängt von der Komplexität des Geschäftsprozesses ab. Bei einfachen Workflows reicht die Choreografie aus. Komplexe Geschäftsprozesse erfordern eine zentrale Steuerung, um die Konsistenz zu gewährleisten. In diesem Kontext unterstützen wir Unternehmen im Rahmen unserer IT-Consulting & Digitale Strategie dabei, die passende Architektur zu wählen.

Ein kritischer Punkt ist die Idempotenz. Da Nachrichten in verteilten Systemen mehrfach zugestellt werden können, müssen sowohl die ursprünglichen als auch die kompensierenden Transaktionen idempotent implementiert sein. Ohne diese Eigenschaft führt die Kompensationslogik zu inkonsistenten Datenzuständen, da eine Kompensation mehrfach ausgeführt werden könnte.

Wir empfehlen für Geschäftsprozesse mit mehr als fünf beteiligten Services konsequent den Einsatz eines Orchestrators. Die dezentrale Choreografie führt bei steigender Komplexität zu einem unübersichtlichen „Event-Spaghetti“, was das Debugging und die Wartung der Kompensationspfade massiv erschwert. Ein zentraler State-Machine-Ansatz ist hier die einzige Möglichkeit, die systemweite Transparenz und Zuverlässigkeit zu sichern.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt