Eine Saga verwaltet eine Geschäftstransaktion, die sich über mehrere Services als eine Sequenz von lokalen Transaktionen erstreckt. Wenn ein Schritt fehlschlägt, führt die Saga kompensierende Transaktionen aus, um frühere Schritte rückgängig zu machen — es gibt kein verteiltes Rollback.
Two-Phase Commit über Services ist langsam, sperrt Ressourcen und koppelt die Verfügbarkeit. Sagas bieten eventuelle Konsistenz ohne verteilte Sperren.
Services reagieren auf die Ereignisse voneinander; es gibt keinen zentralen Koordinator.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
Ein Orchestrator teilt jedem Service mit, was zu tun ist, und reagiert auf die Ergebnisse.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspekt | Choreographie | Orchestrierung |
|---|---|---|
| Koordination | Verteilt (Ereignisse) | Zentralisiert |
| Kopplung | Lockerer | Koordinator kennt den Flow |
| Sichtbarkeit | Schwer zu verfolgen | Leicht zu verfolgen |
| Beste für | Einfach, wenige Schritte | Komplex, viele Schritte |
Kompensationen müssen idempotent sein und den Fall behandeln, in dem der ursprüngliche Schritt teilweise erfolgreich war. Entwerfen Sie sie sorgfältig.
Sagas sind die Art, wie Sie die Datenkonsistenz über Services hinweg aufrechterhalten, ohne die Kosten und Kopplung verteilter Transaktionen.
Die Wahl zwischen Choreographie und Orchestrierung tauscht Einfachheit gegen Sichtbarkeit ein: Ereignisse skalieren locker, werden aber schnell verwickelt, während ein Orchestrator komplexe Logik auf Kosten einer zusätzlichen auszuführenden Komponente zentralisiert.