Saga Pattern

Du definierst Schritte und Rückwärts-Schritte:

• Schritt 1: BucheFlug() -> Undo: StorniereFlug()
• Schritt 2: BucheHotel() -> Undo: StorniereHotel()
• Schritt 3: BucheMietwagen() -> Undo: StorniereMietwagen()

Ablauf bei Fehler in Schritt 3: Automatischer Rollback: StorniereHotel() -> StorniereFlug(). Das System ist am Ende wieder sauber (State: Failed), aber kein Geld ist verloren.

1. Choreography vs. Orchestration

Wie bei EDA.

• Choreography: Flug-Service sendet "FlugGebucht". Hotel-Service hört zu. Wenn Hotel failt, sendet er "HotelFailed". Flug-Service hört zu und storniert. (Chaotisch).
• Orchestration: Ein "Saga Coordinator" (State Machine) ruft explizit die Services auf und kümmert sich um die Fehlerbehandlung. (Übersichtlicher, z. B. Netflix Conductor, AWS Step Functions).

2. Isolation (Das 'I' in ACID fehlt)

Während die Saga läuft (Flug gebucht, Hotel noch nicht), sieht die Welt einen inkonsistenten Zustand ("User hat Flug"). Andere Prozesse könnten das sehen. Sagas sind nur ACD (Atomicity, Consistency, Durability), aber keine Isolation.

1. Orchestration vs. Choreography

Die Wahl zwischen den beiden Varianten ist ein klassischer Trade-off zwischen Komplexität und Kopplung.

• Choreography ist "dezentraler Punkrock". Jeder Service weiß, auf welche Events er reagieren muss. Es gibt keinen Single-Point-of-Failure. Aber: Es ist fast unmöglich, den Status der gesamten Saga zu monitoren. Bei 50 Services blickt niemand mehr durch, warum eine Bestellung vor 3 Stunden hängen geblieben ist.
• Orchestration nutzt einen zentralen "Saga Manager" (eine State-Machine). Dieser ruft die Services auf. Das ist "Enterprise-Kontrolle". Du hast ein zentrales Dashboard, siehst Timeouts sofort und kannst Kompensationen manuell triggern. Aber: Der Orchestrator ist ein "God Object" und muss hochverfügbar sein (z.B. via Temporal.io oder Camunda).

2. Semantische Kompensation (Undo in der echten Welt)

In einer DB ist ein Rollback einfach (Speicherzustand zurücksetzen). In einer Saga ist das oft unmöglich. Wenn Schritt 2 darin bestand, dem Kunden eine E-Mail zu senden ("Flug gebucht!"), kannst du diese E-Mail nicht "un-senden". Die Kompensation muss semantisch sein: Du schickst eine zweite E-Mail ("Sorry, Flug doch nicht gebucht!"). In der Logistik bedeutet das: Wenn die Kreditkarte schon belastet wurde, musst du eine Rückbuchung (Refund) einleiten. Das dauert Tage. Das System muss mit diesem "Intermediate State" (Kunde hat bezahlt, aber noch keine Ware) klarkommen.

3. Isolation & Countermeasures (Das verlorene 'I' von ACID)

Da Sagas keine Datenbank-Locks über Stunden halten können (das würde das System killen), fehlt die Isolation. Andere User sehen Daten, während die Saga noch "schwimmt". Profis nutzen Countermeasures:

• Semantic Lock: Ein Datensatz wird als "Pending" markiert. Er ist in der DB, aber die App ignoriert ihn für andere Käufe.
• Pessimistic View: Zeige dem User erst nach 5 Minuten ("Erfolg!"), wenn die Saga sicher durch alle kritischen Phasen ist.
• Rethink Architecture: Versuche, kritische Schritte (Bezahlung) ans Ende der Kette zu schieben, damit die Kompensationen weniger schmerzhaft sind.