En saga administrerer en forretningstransaksjon som strekker seg over flere tjenester som en sekvens av lokale transaksjoner. Hvis et trinn mislykkes, kjører saga-en kompenserende transaksjoner for å angre tidligere trinn — det finnes ingen distribuert rollback.
To-fase commit over tjenester er langsom, låser ressurser og koblet tilgjengelighet. Sagaer gir eventuelle konsekvens uten distribuerte låser.
Tjenester reagerer på hverandres hendelser; ingen sentral koordinator.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
En orkestrator forteller hver tjeneste hva den skal gjøre og reagerer på resultater.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspekt | Koreografi | Orkestrering |
|---|---|---|
| Koordinering | Distribuert (hendelser) | Sentralisert |
| Kobling | Løsere | Koordinatoren vet flyt |
| Synlighet | Vanskelig å følge | Lett å spore |
| Best for | Enkelt, få trinn | Kompleks, mange trinn |
Kompensasjoner må være idempotente og håndtere tilfelle der det originale trinnet delvis lyktes. Design dem nøye.
Sagaer er hvordan du holder data konsistent over tjenester uten kostnaden og koplingen av distribuerte transaksjoner.
Valg mellom koreografi og orkestrering avveier enkelhet for synlighet: hendelser skaleres løst men blir rotete, mens en orkestrator sentraliserer kompleks logikk på bekostning av en mer komponent å kjøre.