Das Saga-Muster (englisch Saga Pattern) ist eine Entwurfsmethode für langlaufende Abläufe in verteilten Systemen: Ein Gesamtprozess wird in eine Kette lokaler Transaktionen zerlegt, und falls ein Schritt fehlschlägt, machen kompensierende Aktionen die bereits abgeschlossenen Schritte rückgängig. Im Gegensatz zu klassischen verteilten Transaktionen hält eine Saga keine globalen Locks – jeder Teilschritt wird sofort committet.

Ursprung: Das SAGAS-Paper von 1987

Das Muster geht auf das Paper SAGAS von Hector Garcia-Molina und Kenneth Salem zurück (ACM SIGMOD 1987). Sie schlugen vor, langlaufende Transaktionen (Long-lived Transactions) in eine Folge kurzer lokaler Transaktionen T1 bis Tn zu zerlegen, die jeweils einzeln committen. Fällt ein Schritt aus, werden die bereits ausgeführten Schritte durch Kompensationstransaktionen (Compensating Transactions) zurückgenommen.

Choreografie oder Orchestrierung

Eine Saga lässt sich auf zwei Arten steuern. Bei der Choreografie reagieren die Services über Events aufeinander – es gibt keine zentrale Instanz, die Systeme bleiben lose gekoppelt. Bei der Orchestrierung übernimmt ein zentraler Orchestrator die Kontrolle und ruft die Services Schritt für Schritt auf. Werkzeuge wie Temporal, Camunda oder Axon bilden solche Orchestratoren ab.

Beispiel: Reisebuchung

  1. Flug buchen: Transaktion committet.
  2. Hotel buchen: Transaktion committet.
  3. Mietwagen buchen: schlägt fehl.

Jetzt werden die Schritte 1 und 2 kompensiert, also Flug und Hotel storniert. Der Kunde sieht am Ende einen konsistenten Zustand, ohne dass während des gesamten Ablaufs eine Sperre auf den Buchungsdaten lag. Genauso arbeiten Bestell-Abläufe im E-Commerce: Die Zahlung wird autorisiert, der Versand geplant, und bei einem Fehler wird die Zahlung zurückgebucht.

Grenzen und Einsatzgebiete

Sagas eignen sich für Microservices und Abläufe, die Minuten oder Stunden dauern können – etwa Reisebuchungen oder Bestellprozesse. Wer dagegen eine kurze, strikt atomare Operation auf wenigen Knoten braucht, setzt besser auf das Two-Phase-Commit-Protokoll. Ein Nachteil der Saga ist, dass Zwischenzustände für andere Systeme sichtbar sind; die Konsistenz stellt sich wie bei Eventual Consistency erst nach und nach ein.

Zusammenfassung

  • Saga zerlegt langlaufende Prozesse in kurze lokale Transaktionen.
  • Fehlgeschlagene Schritte werden durch Kompensation zurückgenommen.
  • Choreografie entkoppelt, Orchestrierung kontrolliert zentral.

Verwandte Grundlagen: Strong Consistency, Sharding, Datenbank-Replikation.