Saga menaxhon një transaksion biznesi që shtrihet në më shumë shërbime si një sekuencë transaksionesh lokale. Nëse një hap dështon, saga ekzekuton transaksionet kompensuese për të zhbërë hapat e mëparshëm — nuk ka reversali të shpërndarë.
Pse jo një transaksion i shpërndarë?
Dy-faza commit nëpër shërbime është i ngadaltë, bllokuese zëra dhe çifton disponibilitetin. Sagat japin konsistencë përfundimtare pa bllokuese të shpërndarë.
Koreografia (event-driven)
Shërbime reagojnë ndaj ngjarjeve të njëra-tjetrës; nuk ka një koordinator qendror.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
Orkestracioni (koordinator qendror)
Një orkestrator tregon secilit shërbim çfarë të bëjë dhe reagon ndaj rezultateve.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
Krahasimi
| Aspekti | Koreografia | Orkestracioni |
|---|---|---|
| Koordinimi | I shpërndarë (ngjarje) | I centralizuar |
| Çiftimi | Më i lirshëm | Koordinatori di rrjedhën |
| Dukshmëria | E vështirë për të ndjekur | E lehtë për të ndjekur |
| Më i mirë për | E thjeshtë, pak hapa | Komplekse, shumë hapa |
Rrezik
Kompensimet duhet të jenë idempotent dhe të trajtojnë rastin kur hapi origjinal dështoi pjesërisht. Dizajnoni ato me kujdes.
Pse ka rëndësi
Sagat janë se si e mbani të dhënat koherente në të gjithë shërbimeve pa koston dhe çiftimin e transaksioneve të shpërndarë.
Zgjedhja e koreografisë kundrejt orkestracionit ndryshon thjeshtësinë për dukshmërinë: ngjarjet shkallëzohen lirshëm por bëhen të ngatërruar, ndërsa një orkestrator centralizon logjikën komplekse me koston e një komponenti më shumë për të xhiruar.