Slovník pojmů

Saga Pattern

Sága skládá jeden businessový proces z několika samostatně potvrzených kroků. Nevytváří klasickou distribuovanou ACID transakci a kompenzace není automatický rollback.

Stručná definice

Každý účastník potvrdí vlastní krok a proces pokračuje podle výsledku.

Objednávka může postupně vzniknout, rezervovat sklad, zahájit platbu a přejít do potvrzeného stavu. Každý krok proběhne ve vlastní lokální transakci a jeho výsledek spustí další krok. Mezi kroky je systém v platném, ale průběžném stavu, například PAYMENT_PENDING; klient ani operátor nesmějí tento stav zaměnit za dokončený výsledek.

Když pozdější krok selže podle businessového pravidla, sága spustí kompenzace pro dříve dokončené kroky. Uvolnění skladu, zrušení objednávky nebo refundace jsou nové doménové operace s vlastními pravidly, nikoli návrat času. Mohou také selhat, být provedeny později nebo vyžadovat ruční zásah.

Jaký problém řeší

Jeden proces překračuje několik transakčních hranic.

V distribuovaném systému obvykle nelze obalit sklad, platbu, dopravu a objednávku jednou databázovou transakcí. Sága dává jejich lokálním změnám explicitní pořadí, stav a chybové cesty.

vytvoření objednávky, rezervace skladu a zahájení platby v různých službách
aktivace zákaznického účtu spolu s provisioningem externí služby
rezervace cesty složená z dopravy, ubytování a platby
vrácení zboží, které zahrnuje příjem skladu, refundaci a účetní záznam
dlouhý import nebo schvalovací workflow rozdělené do opakovatelných kroků

Praktický příklad a diagram

Objednávka, sklad a neúspěšná platba

Order Service vytvoří objednávku ve stavu PENDING. Inventory Service rezervuje položky a odpoví InventoryReserved. Payment Service se pokusí autorizovat platbu. Pokud uspěje, objednávka přejde do CONFIRMED a může následovat doprava. Pokud banka platbu odmítne, workflow nevrací předchozí databáze technickým rollbackem.

Místo toho spustí ReleaseInventory a změní objednávku na PAYMENT_FAILED nebo CANCELLED. Uvolnění zásoby může mezitím vyžadovat jiné pravidlo než původní rezervace a může samo selhat. Proces proto uchová pokus, důvod, poslední úspěšný krok a stav kompenzace; alarm upozorní na ságu, která překročila očekávaný čas.

Textový diagram a jeho alternativa

Create Order
      ↓
Reserve Inventory
      ↓
Authorize Payment
 ├─ success → Confirm Order
 └─ failed
      ↓
Compensation workflow
      ↓
Release Inventory
      ↓
Cancel Order

Jak funguje

Dopředné kroky a kompenzační cesta

Sekvence je textovou alternativou diagramu. Konkrétní sága může mít jiné pořadí, paralelní větve i body, po kterých už není plná kompenzace možná.

Vznik instance procesu Workflow dostane stabilní saga_id a uloží počáteční stav. Opakovaný požadavek nesmí založit druhou objednávku ani druhou instanci stejného business procesu.
Lokální transakce Každá služba ověří své pravidlo a atomicky změní pouze vlastní data. Po potvrzení publikuje výsledek nebo vrátí odpověď, která určí další krok.
Částečné selhání Timeout neříká, zda vzdálený krok proběhl. Koordinace proto nejprve dohledává stav nebo bezpečně opakuje příkaz, místo aby automaticky předpokládala neúspěch.
Kompenzace Při definitivním businessovém neúspěchu následují zrušovací operace pro kroky, které je možné a nutné vyvážit. Jejich pořadí vychází z domény, nemusí být přesným obrácením dopředných kroků.
Konečný nebo intervenční stav Proces skončí jako potvrzený, zrušený, částečně kompenzovaný nebo vyžadující ruční řešení. Každý konec musí být dohledatelný pro API, podporu i monitoring.

Dvě varianty koordinace

Choreografie rozděluje rozhodování, orchestrace ho soustředí.

Oba přístupy používají lokální transakce a zprávy. Volba ovlivňuje čitelnost procesu, vazby mezi službami a místo, kde se uchovává jeho stav.

Choreografie

Každá služba reaguje na událost předchozího účastníka a publikuje vlastní výsledek. Není zde centrální koordinátor; jednoduchý tok má málo infrastruktury, ale s více větvemi může být pořadí a chybová cesta rozptýlená v mnoha handlerech.

Orchestrace

Samostatný orchestrátor uchovává stav procesu, posílá příkazy účastníkům a podle odpovědí volí další krok. Zvyšuje přehlednost složitého workflow, nesmí však převzít interní doménová pravidla jednotlivých služeb ani se stát nedostupným bodem bez obnovy.

Stav ságy

Stabilní identifikátor, aktuální krok, verze, pokusy a výsledky umožňují po restartu pokračovat. Stav nemá existovat jen v paměti procesu nebo v nedohledatelné řadě logů.

Spolehlivé zprávy

Outbox Pattern může atomicky spojit lokální změnu účastníka s publikováním výsledku. Neřeší sám rozhodnutí ságy; pouze snižuje riziko, že potvrzený krok ztratí navazující zprávu.

Izolace a souběh

Sága neposkytuje automatickou izolaci mezi dvěma současnými procesy. Stavové přechody, verze, rezervace, constrainty nebo sémantické zámky musí zabránit tomu, aby jedna sága použila prostředek, který už změnila jiná.

Výhody a omezení

Řízené dílčí změny nahrazují pohodlí automatického rollbacku.

Možné přínosy

koordinace dlouhého procesu bez jedné distribuované databázové transakce
každá služba zachová vlastní data a lokální pravidla
výpadek jednoho kroku lze dočasně absorbovat a později bezpečně zopakovat
explicitní stav dovolí zobrazit průběh klientovi a dohledat incident operátorem

Omezení a časté chyby

kompenzace nemusí přesně obnovit původní svět; e-mail nelze odvolat a cena refundace se může změnit
kompenzační operace může selhat a potřebuje vlastní retry, idempotenci i eskalaci
choreografie s mnoha účastníky může skrýt proces v síti událostí a vytvořit cykly
orchestrátor bez perzistentního stavu nebo vysoké dostupnosti se stane křehkým bodem
sága bez ochrany souběhu dovolí jiným transakcím pozorovat a měnit průběžný stav

Kdy dává smysl

Pro skutečný proces přes několik samostatných commitů.

Mikroservisní architektura často vytváří transakční hranice, kvůli kterým je sága užitečná, ale mikroservisy nejsou podmínkou. Stejný vzor lze použít při práci s externím platebním API nebo více moduly, které nemají společný commit. Podstatný je dlouhotrvající business proces a potřeba řídit částečné výsledky.

Jednoduchý proces nad několika tabulkami v jedné databázi ságu obvykle nepotřebuje. Krátká lokální transakce poskytne silnější a jednodušší garance. Sága také není synonymum CQRS ani Event Sourcingu: může je kombinovat, ale oddělení command/query a ukládání historie událostí řeší jiné problémy.

Před použitím je nutné zjistit, zda každý dopředný krok má přijatelnou kompenzaci. Některé akce mají bod bez návratu, například fyzicky předaná zásilka. Workflow pak místo předstírání návratu do původního stavu přechází do nového procesu, například reklamace, refundace nebo manuálního řešení.

Odolnost a observabilita

Každý krok musí být opakovatelný, měřitelný a dohledatelný.

Workflow je produkční stavový automat. Nestačí spoléhat na pořadí logů nebo na to, že broker doručí každou zprávu právě jednou.

zajistit idempotenci příkazů, odpovědí i kompenzací pomocí stabilních identifikátorů
nastavit timeout, omezený retry a pravidlo pro neznámý výsledek každého vzdáleného kroku
ukládat saga_id, korelační ID, aktuální stav, verzi a historii rozhodnutí
měřit délku procesu, počet opakování, selhané kompenzace a instance čekající na zásah
testovat pád před a po commitu každého kroku, duplicitu, změnu pořadí i souběžné ságy
navrhnout oprávnění a audit ručního dokončení, přeskočení nebo kompenzace

Časté otázky

Sága bez představy globálního rollbacku

Je Saga Pattern distribuovaná ACID transakce?

Ne. Jednotlivé lokální transakce se potvrzují samostatně a mezi kroky chybí globální atomita i automatická izolace. Konzistenci procesu zajišťují stav workflow, zprávy a kompenzační operace.

Vrátí kompenzace systém vždy přesně do původního stavu?

Ne. Kompenzace vytváří nový platný business stav. Může například uvolnit rezervaci nebo refundovat platbu, ale neodvolá přečtený e-mail, uplynulý čas ani všechny externí náklady.

Je lepší choreografie, nebo orchestrace?

Záleží na složitosti toku. Choreografie může být přiměřená pro několik jasných reakcí; orchestrace zpřehlední větvení, timeouty a kompenzace. Obě varianty potřebují perzistentní stav a observabilitu v odpovídajícím místě.

Co dělat, když kompenzace selže?

Uložit její stav, bezpečně ji opakovat a po překročení limitu upozornit obsluhu. Některé případy vyžadují manuální rozhodnutí nebo nový opravný proces; nesmějí zmizet jen v logu.

Potřebuje každá sága message broker?

Ne nutně. Koordinace může používat i synchronní API a perzistentní workflow engine. Jakmile ale překračuje síťové hranice, musí řešit timeouty, neznámé výsledky, opakování a obnovu po pádu bez ohledu na transport.

Jak navrhuji vícefázové procesy

Průběžný stav, chyby a kompenzace modeluji jako součást businessového toku.

U integračních procesů určuji lokální hranice, idempotentní kroky, očekávané timeouty i cestu k ručnímu dokončení.

Zobrazit přístup k architektuře aplikací Nezávazně probrat projekt