En saga administrerer en forretningtransaktion, der spænder over flere tjenester som en sekvens af lokale transaktioner. Hvis et trin mislykkes, udfører sagen kompenserende transaktioner for at fortryde tidligere trin — der er ingen distribueret rollback.
To-fase commit på tværs af tjenester er langt, låser ressourcer og knytter tilgængelighed. Sagas giver eventuel konsistens uden distribuerede låse.
Tjenester reagerer på hinandens begivenheder; ingen central koordinator.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
En orkestrator fortæller hver tjeneste, hvad den skal gøre, og reagerer på resultater.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspekt | Choreografi | Orchestration |
|---|---|---|
| Koordination | Distribueret (events) | Centraliseret |
| Kobling | Løsere | Koordinator kender flow |
| Synlighed | Svær at følge | Let at spore |
| Bedst til | Simpel, få trin | Kompleks, mange trin |
Kompensationer skal være idempotente og håndtere det tilfælde, hvor det originale trin delvist lykkedes. Design dem omhyggeligt.
Sagas er hvordan du holder data konsistent på tværs af tjenester uden omkostninger og kobling af distribuerede transaktioner.
Valg af choreografi versus orchestration bytter enkelhed til gengæld for synlighed: events skaleres løst, men bliver vanskeligt at følge, mens en orkestrator centraliserer kompleks logik på bekostning af en ekstra komponent at køre.