Saga Pattern

In der modernen Softwareentwicklung – insbesondere bei verteilten Systemen und Microservices-Architekturen – stoßen klassische Transaktionsmodelle wie ACID schnell an ihre Grenzen. Wie lassen sich lang andauernde, über mehrere Services verteilte Geschäftsprozesse dennoch konsistent gestalten, ohne Systemverfügbarkeit oder Fehlertoleranz zu gefährden?

Mit genau dieser Fragestellung hat sich unser interner Arbeitskreis „Plattform“ befasst – und dabei das Saga-Pattern näher untersucht. Dieses Entwurfsmuster wurde bereits 1987 von Hector Garcia-Molina und Kenneth Salem beschrieben und bietet eine pragmatische Lösung für genau diese Herausforderung. Es erlaubt die Modellierung langer Transaktionen durch eine Abfolge kleiner, atomarer Transaktionen, die sich bei Fehlern über definierte Kompensationsaktionen rückgängig machen lassen.

Dieser Beitrag gibt einen praxisorientierten Überblick über das Saga-Pattern, stellt typische Anwendungsfälle vor und beleuchtet verschiedene Implementierungsstrategien in heutigen Systemen.

Hintergrund und Motivation

Verteilte Datenhaltung In Microservices-Architekturen verwaltet jeder Service seine eigene Datenbank. Eine zentrale Transaktionskontrolle über mehrere Services hinweg ist dadurch kaum umsetzbar. Das erschwert es, eine konsistente Gesamtsicht über alle beteiligten Systeme zu gewährleisten.

Lang andauernde Geschäftsprozesse Viele Geschäftsprozesse bestehen aus mehreren Einzelschritten, die sich über längere Zeiträume – von Minuten bis zu mehreren Stunden – erstrecken. Klassische Transaktionsmodelle sind für solche Abläufe ungeeignet, da sie über längere Zeit Systemressourcen blockieren und anfällig für Fehler sind.

Fehlertoleranz ohne globale Sperren Globale Transaktionen über mehrere Services hinweg erfordern Sperrmechanismen, die die Systemverfügbarkeit einschränken. Kommt es zu einem Teilausfall, ist oft unklar, wie mit inkonsistenten Zwischenzuständen umgegangen werden soll.

Asynchrone Kommunikation In modernen Systemarchitekturen erfolgt die Kommunikation zwischen Services häufig asynchron – etwa über Events oder Nachrichten. Das erschwert eine zentrale Ablaufsteuerung und erhöht die Komplexität bei der Fehlerbehandlung.

Das Saga Pattern im Überblick

Das Saga Pattern wurde ursprünglich 1987 von Hector Garcia-Molina und Kenneth Salem als Transaktionsmodell für lang andauernde Prozesse innerhalb monolithischer Systeme beschrieben. Ziel war es, sogenannte Long-Lived Transactions (LLTs) in mehrere kleinere, voneinander unabhängige Transaktionen zu unterteilen. So sollte die Ressourcennutzung in klassischen Datenbanksystemen optimiert und das Risiko langanhaltender Sperren reduziert werden. Anstelle einer zentralen, lang laufenden Transaktion sollten die Einzelschritte jeweils atomar ausgeführt und bei Fehlern durch sogenannte Kompensationsaktionen rückgängig gemacht werden.

Heute erfährt das Saga Pattern eine neue Relevanz – insbesondere im Kontext verteilter Systeme und Microservices-Architekturen. Die Grundidee bleibt dabei unverändert: Eine LLT wird in mehrere lokale Transaktionen unterteilt, die isoliert und atomar ausgeführt werden. Im Gegensatz zu klassischen Zwei-Phasen-Commit-Verfahren (2PC) erfolgt die Ausführung sequenziell. Kommt es zu einem Fehler, werden die bereits ausgeführten Transaktionen durch definierte Kompensationsaktionen zurückgesetzt. So kann die Konsistenz des Gesamtsystems auch ohne globale Sperren gewahrt bleiben.

Eine verteilte Saga besteht typischerweise aus vier zentralen Bausteinen:

• Transaktionsschritte
  Einzelne Aktionen, die lokal innerhalb eines Services ausgeführt werden und keine globale Sperrung erfordern.
• Kompensationsaktionen
  Umkehrbare Aktionen, mit denen fehlerhafte oder inkonsistente Zustände rückgängig gemacht werden können.
• Koordination
  Entweder zentral durch einen Koordinator-Service (Orchestration) oder dezentral durch Kommunikation zwischen den beteiligten Services (Choreography).
• Statusverfolgung
  Der aktuelle Zustand einer Saga wird in der Regel persistiert – etwa in einer Prozesstabelle – um Fehler nachvollziehbar zu behandeln und die Ausführung der Teilschritte transparent zu gestalten.

Durch diese Struktur lassen sich sowohl lang andauernde Abläufe in monolithischen Anwendungen als auch komplexe Prozesse in verteilten Architekturen konsistent, fehlertolerant und skalierbar abbilden.

Beispiel: Flugbuchung mit Hotel und Mietwagen

1. Transaktionsschritt 1: Flugbuchung

• Aktion: Der Flugbuchungs-Service bucht einen Flug für die reisende Person und reserviert einen Sitz.
• Erfolg: Der Flug wird erfolgreich gebucht und bestätigt.
• Kompensation: Falls die folgenden Schritte fehlschlagen, wird die Flugbuchung storniert.

2. Transaktionsschritt 2: Hotelbuchung

• Aktion: Der Hotelbuchungs-Service reserviert ein Zimmer für die reisende Person.
• Erfolg: Das Zimmer wird erfolgreich reserviert und bestätigt.
• Kompensation: Falls die nächsten Schritte fehlschlagen, wird die Hotelbuchung storniert.

3. Transaktionsschritt 3: Mietwagenbuchung

• Aktion: Der Mietwagen-Service reserviert ein Fahrzeug für die reisende Person.
• Erfolg: Das Fahrzeug wird erfolgreich reserviert.
• Kompensation: Falls der Mietwagen nicht verfügbar ist oder ein Fehler auftritt, wird die Mietwagenbuchung rückgängig gemacht.

Ablauf:

Erfolgsdurchlauf:

Fehlerdurchlauf:

Vor- und Nachteile des Saga-Patterns

Das Saga-Pattern bringt eine Reihe technischer Vorteile mit sich – insbesondere im Kontext verteilter Systeme. Gleichzeitig stellt es jedoch auch spezifische Anforderungen an die Systemarchitektur, das Fehlerhandling und die Fachlogik.

Vorteile:

• Verzicht auf globale Sperren
  Durch die Aufteilung in lokale Transaktionen entfällt die Notwendigkeit globaler Sperrmechanismen über Systemgrenzen hinweg.
• Transaktionskontrolle ohne verteiltes Commit-Protokoll
  Sagas umgehen die Komplexität und die Liveness-Probleme klassischer Zwei-Phasen-Commit-Protokolle (2PC). Das erhöht die Verfügbarkeit der Systeme.
• Fehlerbehandlung über definierte Kompensationspfade
  Fehler in Teilschritten werden nicht durch ein vollständiges Rollback behandelt, sondern über explizit modellierte Kompensationsaktionen.
• Steuerbare Zustandsverwaltung
  Der Fortschritt der Saga kann über eine persistente Prozesstabelle verfolgt und im Fehlerfall gezielt fortgesetzt oder reaktiviert werden.

Nachteile:

• Komplexität der Kompensationslogik
  Kompensationen müssen individuell pro Geschäftsfall entworfen werden. Sie sind nicht automatisch aus den Vorwärtsoperationen ableitbar und erfordern tiefes fachliches Verständnis.
• Schwierige Kontrolle bei Nebenläufigkeit
  Parallele oder konkurrierende Sagas können Race Conditions und Interferenzen verursachen, die sich nicht automatisiert auflösen lassen.
• Eventual Consistency statt sofortiger Konsistenz
  Zwischenzustände können systemweit inkonsistent sein, bis alle Schritte abgeschlossen oder kompensiert wurden. Das ist nicht für alle Anwendungsszenarien akzeptabel.
• Fehlende transitive Isolation
  Es gibt keine übergreifende Transaktionsisolation – andere Prozesse können auf inkonsistente Daten zugreifen, bevor die Saga abgeschlossen ist.

Wann sich der Einsatz des Saga Patterns lohnt – und wann nicht

Das Saga Pattern bietet eine robuste Alternative zu klassischen Transaktionsmodellen in verteilten Systemarchitekturen. Durch den Verzicht auf globale Sperren und zentrale Commit-Protokolle verbessert es die Skalierbarkeit und Verfügbarkeit – besonders in Microservices-basierten Anwendungen. Gleichzeitig ermöglicht es eine kontrollierte Fehlerbehandlung über klar definierte Kompensationspfade und erlaubt die Steuerung lang andauernder Geschäftsprozesse mit vielen Teilschritten.

Geeignete Anwendungsfälle

Das Pattern ist vor allem dann sinnvoll, wenn:

• Prozesse aus mehreren, logisch voneinander entkoppelten Schritten bestehen
• keine sofortige Konsistenz erforderlich ist (Stichwort: Eventual Consistency)
• eine hohe Systemverfügbarkeit wichtiger ist als vollständige Isolation
• eine zentrale Koordination nicht praktikabel oder nicht gewünscht ist (z. B. in Event-getriebenen Architekturen)
• oder wenn Kompensationsaktionen in der Geschäftslogik ohnehin bereits vorgesehen sind (z. B. bei Stornierungen, Rückbuchungen, Reversals).

Typische Einsatzbereiche sind etwa Buchungs- und Zahlungsprozesse, Bestellabwicklungen in E-Commerce-Systemen oder auch User-Onboarding-Prozesse, die mehrere Teilsysteme involvieren. Sagas ermöglichen die Umsetzung verteilter Transaktionen, ohne dass alle beteiligten Systeme gleichzeitig angepasst oder tief integriert werden müssen. Im Vergleich zu 2PC reduziert dies den Aufwand für Schnittstellendesign und Koordination erheblich. Das ist besonders vorteilhaft in frühen Projektphasen oder bei externer Systemintegration.

Wann vom Einsatz abzuraten ist

Das Saga Pattern ist nicht für alle Szenarien geeignet. Davon abzuraten ist insbesondere, wenn:

• eine strikte Konsistenz über alle Systeme hinweg zu jedem Zeitpunkt erforderlich ist
• Geschäftsprozesse sehr stark miteinander verflochten sind und keine klaren Teilschritte gebildet werden können
• die Kompensationslogik zu komplex oder fachlich nicht eindeutig definierbar ist
• oder die Kontrollierbarkeit bei Nebenläufigkeit essenziell ist (z. B. bei parallelen Prozessen mit harten Abhängigkeiten)

Gerade in sicherheitskritischen Anwendungen – etwa im Finanzwesen oder im Gesundheitsbereich – kann der Verzicht auf sofortige Konsistenz und Isolation zu untragbaren Risiken führen.

Unser Fazit

Das Saga Pattern ist ein wertvolles Werkzeug für moderne, verteilte Systeme – allerdings kein Selbstläufer. Der Erfolg hängt stark von der konkreten Umsetzung ab. Wer es einsetzt, muss die Herausforderungen bei Kompensation, Nebenläufigkeit und Konsistenz aktiv adressieren. Richtig eingesetzt, ermöglicht das Muster jedoch fehlertolerante, skalierbare und nachvollziehbar orchestrierte Prozesse in einer Microservices-Welt.