Saga Pattern
Saga: start from the problem
See the responsibilities
Checkout reserves inventory and charges payment under different owners. One local database transaction cannot automatically roll both back if a later service fails. The order needs an explicit pending and recovery state.
This is a workflow and resilience pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Saga addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Saga expresses a business workflow as local transactions with defined compensating actions. A coordinator can record and drive the sequence, or participants can react to events under a shared contract. Intermediate states can be visible, so the product must explain them.
The example models stock reservation followed by a rejected charge, then releases that reservation. Its state is local and its compensation succeeds immediately. Real workflow progress, retries and uncertain payment outcomes need durable mechanisms.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
let reserved = false;
const reserve = () => { reserved = true; };
const charge = () => false;
const release = () => { reserved = false; };
reserve();
if (!charge()) release();
console.log('reserved=' + reserved);Expected output
reserved=falseChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it for justified multi-owner workflows when a single transaction boundary is unavailable and compensation fits the business contract.
A refund is a new action, not erased history. Compensation can fail and require retry or review. A timeout does not prove the charge was rejected. Keep stable operation identities and inspect uncertain outcomes before issuing another effect.
Distinguish the neighbouring patterns
Two-phase commit coordinates compatible resource managers toward an atomic decision. Saga uses local commits and business recovery. Command undo and Memento are local action/state techniques with different boundaries.
Follow the full distributed transaction comparison, durable participant publication, local action representation to compare the specific responsibility before combining patterns.
For further reading, use AWS’s Saga orchestration guidance. Compare it with this original example and the guarantee required by your application.
Check your pattern reasoning
Check your pattern reasoning
Compare the pattern boundaries
Name the responsibility before choosing the pattern
For Saga, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside local action representation.
Reaching the recap and completing the quizzes are separate milestones.