Saga Pattern¶
A distributed-workflow protocol — instantiates Compensating Transaction
Runs a long, multi-service process as a chain of local commits, each paired with a defined compensating action that fires in reverse order when a later step fails.
When a business process spans several services that cannot share one database transaction, there is no global rollback to fall back on — each step commits locally and its effect is immediately real. The Saga Pattern replaces the missing rollback with a designed counter-move: every forward step is authored together with a compensating step that semantically undoes it, and if any later step fails, the already-committed steps are unwound by running their compensations backward down the chain. Its defining idea is that recovery is not a rewind but a second forward journey — a cancel, a refund, a release — because the original effect already happened and cannot be pretended away.
Example¶
A trip-booking service reserves a flight, then books a hotel, then rents a car — three separate providers, three separate local commits. The car step fails: no vehicles at the destination. There is no shared transaction to abort, and the flight and hotel are already reserved with real confirmation numbers. The saga's compensation chain runs in reverse: cancel hotel booking, then cancel flight reservation, each of which is itself a live call to that provider, not a memory-rewind. The traveller ends up where they started — nothing booked — but the system got there by two deliberate cancellations, not by pretending the reservations never existed. Had the flight already been ticketed (a non-refundable, externally-binding effect), the saga could only offset it with a refund request, not erase it — which is exactly the kind of step the design must flag ahead of time.
How it works¶
Each step is modelled as a pair: a forward local transaction and its compensating transaction. The forward path runs step by step, and a pivot step (the last irreversible one) marks the point past which the saga commits to completing rather than unwinding. On a downstream failure the coordinator invokes the compensations for all completed steps in reverse order. Coordination is either orchestrated (a central controller issues each step and each compensation) or choreographed (each service reacts to the previous one's event). Unlike two-phase commit, no resource is locked across the whole process — so the saga trades global isolation for availability, and must reason explicitly about intermediate states other actors can see.
Tuning parameters¶
- Orchestration vs. choreography — a central coordinator makes the sequence and its compensations easy to see and audit; event choreography removes the coordinator bottleneck but scatters the recovery logic across services.
- Pivot placement — where the irreversible point sits. Earlier pivots mean fewer steps can be cleanly compensated; deferring irreversible steps to the end keeps more of the saga unwindable.
- Retry-before-compensate threshold — how many times a transient failure is retried before the saga gives up and unwinds. Too eager to compensate wastes recoverable progress; too reluctant strands the process.
- Semantic-lock strength — interim countermeasures (a pending flag, a reserved-but-not-final state) that stop other actors from acting on a step the saga might still compensate.
When it helps, and when it misleads¶
The saga shines wherever a process crosses service or organizational boundaries that can't be wrapped in one atomic transaction — its whole reason to exist is that atomicity is off the table. It keeps systems available under partial failure and makes recovery a first-class, tested path rather than an afterthought.
It misleads when a step's effect is genuinely irreversible and its "compensation" is only a partial offset — a shipped package, a sent notification, a disclosed record. Calling such a step compensable invites the quiet assumption that the saga restores the exact prior state, when at best it reaches an acceptable one under eventual consistency.[1] The classic trap is designing the forward path first and bolting compensations on later, so the compensations are never exercised until a real failure finds their gaps. The discipline is to author each compensation with its forward step, test the unwind path deliberately, and mark irreversible steps as pivots up front.
How it implements the components¶
irreversible_effect_map— identifying each step's pivot status is mapping which effects can only be offset, not erased; the map is what tells the saga how far back it can safely unwind.compensation_trigger— a failed downstream step is the trigger that begins compensation of the already-committed steps, rather than blocking or retrying forever.compensating_action_sequence— the reverse chain of per-step compensating transactions is the saga's core artifact: the ordered set of counter-moves.
It does not decide whether a compensation truly restored an acceptable state — that verification belongs to Operational Reconciliation Workflow — nor does it define the make-whole measure or its caps, which the customer- and finance-facing siblings own.
Related¶
- Instantiates: Compensating Transaction — the saga is its canonical software-engineering realization for long-running distributed work.
- Sibling mechanisms: Operational Reconciliation Workflow · Financial Reversal or Credit · Service Recovery Playbook · Remediation Plan · Corrective Action Request · Contract Cure Provision · Clinical Correction Protocol · Customer Make-Whole Credit · Incident Corrective Action Register
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Saga Pattern operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it runs a long, multi-service process as a chain of local commits, each paired with a defined compensating action that fires in reverse order when a later step fails.
Independent corroboration: The frozen evidence defines Saga Pattern as 'Runs a long, multi-service process as a chain of local commits, each paired with a defined compensating action that fires in reverse order when a later step fails', so its operative form is Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — Saga Pattern includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Chains of local commits paired with compensating actions define the saga pattern in distributed computing.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: runs a long, multi-service process as a chain of local commits, each paired with a defined compensating action that fires in reverse order when a later step fails.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate_origin_disagreement starts from reviewer_a's mechanism-specific evidence: Chains of local commits paired with compensating actions define the saga pattern in distributed computing. Reviewer A proposed alternates=none, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false; reviewer B proposed alternates=engineering_design, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (engineering_design) without an arbitrary cap, selects origin_mode=single_lineage to represent the combined lineage evidence, and records domain_reach=specialized and encyclopedia_synthesis=false. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A saga guarantees eventual consistency, not isolation: between a forward step and its possible compensation, other actors can observe the intermediate state. Semantic locks and status flags mitigate this, but the exposure is inherent to trading atomicity for availability, and downstream consumers must be designed to tolerate it.
References¶
[1] The saga concept originates in Hector Garcia-Molina and Kenneth Salem's 1987 database work on long-lived transactions, which proposed decomposing a long transaction into a sequence of sub-transactions each with a compensating transaction — precisely the forward/compensation pairing used here. withdrawn registry ↩