Zum Hauptinhalt springen

Saga Pattern

Einleitung​

Das Saga Pattern koordiniert mehrstufige Geschäftsprozesse über mehrere Services, ohne globale Transaktionen (2PC).

Statt eines technischen Rollbacks werden bei Fehlern:

kompensierende fachliche Aktionen ausgeführt.

Saga ersetzt keine ACID-Transaktion –
sie implementiert ein anderes Konsistenzmodell.

Einordnung

Saga ist ein Meso-Pattern für verteilte Prozesskoordination.

Typische Kontexte:

  • Microservices
  • Event-Driven Architectures
  • Database-per-Service

Problem:

Ein Geschäftsprozess läuft über mehrere Services,
aber globale Transaktionen sind nicht praktikabel.

Grundprinzip

Kernaussage:

  • Jeder Schritt ist lokal transaktional
  • Fehler lösen Kompensationen aus
  • Gesamtprozess ist eventual consistent

Zwei Varianten

1️⃣ Choreografie​

  • Services reagieren auf Events
  • Kein zentraler Koordinator
  • Logik verteilt sich implizit

Vorteil:

  • Lose Kopplung

Nachteil:

  • Prozesslogik schwer nachvollziehbar

2️⃣ Orchestrierung​

  • Zentraler Saga Coordinator
  • Explizite Prozessdefinition
  • Klarer Kontrollfluss

Vorteil:

  • Bessere Übersicht
  • Klare Fehlerpfade

Nachteil:

  • Zentralisierung
  • Potenzieller Bottleneck

Charakteristika

1️⃣ Lokale Transaktionen​

Jeder Service:

  • führt eigene ACID-Transaktion aus
  • publiziert Event (oft via Outbox)

2️⃣ Kompensation statt Rollback​

Rollback bedeutet:

„Als wäre es nie passiert.“

Kompensation bedeutet:

„Wir führen eine Gegenaktion aus.“

Beispiel:

  • Zahlung reserviert → Zahlung stornieren
  • Lager reserviert → Reservierung aufheben

Nicht jede Aktion ist sauber kompensierbar.

3️⃣ Eventual Consistency​

Zwischen den Schritten existiert:

  • temporäre Inkonsistenz
  • asynchrone Verarbeitung
  • mögliche Zwischenzustände

Fachlich muss das akzeptiert werden.

Vorteile

  • Kein 2-Phase-Commit notwendig
  • Funktioniert mit Database-per-Service
  • Skalierbar in verteilten Systemen
  • Hohe Autonomie der Services

Risiken / typische Fallstricke

1️⃣ Fachlich schwierige Kompensation​

Nicht alles ist reversibel:

  • Versandte E-Mails
  • Externe Banktransaktionen
  • Physische Aktionen

2️⃣ Komplexe Fehlerpfade​

Teilweise erfolgreiche Schritte erzeugen:

  • komplexe Edge Cases
  • Race Conditions
  • Retry-Probleme

3️⃣ Unklare Prozessverantwortung​

Ohne klare Ownership wird Saga:

  • schwer wartbar
  • schwer verständlich

4️⃣ Fehlende Idempotenz​

Retries können:

  • doppelte Reservierungen
  • doppelte Zahlungen

verursachen.

Idempotente Handler sind Pflicht.

Wann sinnvoll?

  • Mehrstufige Geschäftsprozesse
  • Mehrere Datenhoheiten
  • 2PC technisch oder organisatorisch nicht möglich
  • Event-getriebene Architektur

Wann unnötig?

  • Einfacher, lokal transaktionaler Workflow
  • Monolith mit einer Datenbank
  • Geringe Prozesskomplexität

Strategische Perspektive

Saga verschiebt Konsistenz von:

  • technischer Transaktion

zu:

  • fachlicher Prozesssteuerung

Sie erhöht:

  • Modellierungskomplexität
  • Testaufwand
  • Observability-Anforderungen

Sie ist kein Default – sondern eine Reaktion auf verteilte Datenhoheit.

Typische Kombinationen

  • Saga + Outbox
  • Saga + Event-Driven Architecture
  • Saga + Idempotente Consumer
  • Saga + Observability (Tracing pro Prozess)

Fazit

Saga koordiniert verteilte Prozesse ohne globale Transaktionen.

Sie funktioniert gut, wenn:

  • Kompensation fachlich möglich ist
  • Eventual Consistency akzeptiert wird
  • Prozesslogik klar modelliert ist

Sie ersetzt kein ACID-Modell – sie implementiert ein anderes.