Saga

A saga is a business process split into a sequence of local transactions, each committing independently in one system, with a defined way to undo the earlier ones if a later one fails. It is the usual answer when work spans systems that cannot share a transaction.

Garcia-Molina and Salem introduced sagas in 1987 to reduce the resource retention of long-lived transactions. Their model lets local steps commit and interleave with other work while recovery completes the sequence or compensates a partial execution.

Read the guarantee carefully

This recovery contract does not provide the isolation of one transaction across the entire process. Other work can observe the committed effects of steps before the saga finishes.

The paper’s basic sequential model compensates a completed prefix in reverse order.

Its recovery mechanism does not automatically notify or abort transactions that observed those results. That absence of automatic notification is different from prohibiting a workflow from publishing a cancellation or correction event.

A compensation cannot erase an earlier observation or automatically retract everything derived from it. A customer notification, a corrected report, or another service’s adjustment may be required. Implement and track those follow-up actions explicitly. Modern compensation workflows can also use dependency-aware ordering or parallel steps instead of assuming every compensation must run in reverse order.

Local commits leave room for concurrent sagas to overwrite changes or observe intermediate process state. Application controls can reduce that risk: reservations or semantic locks, commutative updates, suitable step ordering, atomic version checks, and operation histories. The pattern does not install those controls for you.

When the shape fits

The original paper assumes relatively independent steps that can tolerate interleaving with other work. That fits processes where one reservation need not freeze every resource for the duration of a larger order.

If correctness depends on unchanged data between steps, a saga alone is insufficient. Add reservations, version validation with conflict handling, or an appropriate stronger transaction boundary. Otherwise, define which intermediate states are acceptable and how failed work is compensated or completed.

Three kinds of step

A useful classification splits a saga’s steps by what can be done when something later goes wrong.

• Compensable steps have an acceptable business reversal if the workflow chooses backward recovery.
• The pivot marks the chosen transition to forward completion. It can be an irreversible step, the last compensable transaction, or the first retryable operation, depending on the workflow.
• Retryable steps after the pivot are designed for safe repetition and completion under stated recovery assumptions. Idempotency alone does not guarantee that a permanent failure will clear.

Locate the pivot by recovery policy rather than physical appearance. A permitted refund can compensate settlement and an authorized return can compensate shipment. Another workflow may cross its pivot while steps are still technically reversible because it commits to forward completion. A disclosure with no acceptable withdrawal path can force an irreversible boundary.

Perform critical validation and reserve required resources before that boundary where feasible. After it, keep durable progress and define the transient-failure assumptions, deadline, and owner for exception handling or manual completion. Repeating a permanently rejected command is not a recovery plan.

The original paper distinguishes backward recovery through compensations from forward recovery using saved progress and the remaining application code. Forward recovery is appropriate only when the missing work can still be completed; the workflow must account for cases where that assumption fails.

Where the coordination lives

Choreography coordinates participants through events. Orchestration gives an explicit controller responsibility for selecting steps and handling their outcomes.

Choreography avoids adding a dedicated coordinator but requires tracking dependencies and testing the participating flow. An orchestrator centralizes progression and recovery logic, which helps with complex workflows but adds a component whose state and availability need protection. Both approaches require operational evidence.

For an audited process across departments, I would favor an orchestrator as a natural place to inspect progress. A choreographed flow can also publish correlated outcomes into a central status projection; separate logs are not its only option. In either case, the view reflects the evidence received and can be incomplete or stale.

What recovery depends on

The saga paper identifies application code as part of recovery: completing missing transactions or executing compensations requires the relevant programs to remain available, alongside recorded progress. A database’s ordinary transaction log does not supply those business operations.

Retain compatible workflow code and state for open instances before retiring or replacing a service. If a compensation cannot finish, preserve its status and evidence and assign an owner to resolve it; a retry loop cannot repair every failure.

A saga coordinates work and records observed progress. Define what counts as business completion and which outcome evidence supports it; a status alone is only as strong as its contract. Comparing participating records through reconciliation is one control, but agreement can miss a shared error or an unobserved physical outcome. The wider design — how the intermediate states, the message delivery, and the business-completion check fit together across an enterprise estate — is worked through in Nothing Rolls Back, and the mechanics of reversal are in compensating transaction. What a saga gives up in exchange is described under two-phase commit. And note that giving up atomicity does not hand you convergence: eventual consistency holds only where propagation is durable, conflicts resolve by a stated rule, and something detects and repairs what was missed — a saga creates the need for those rather than supplying them.

References

• “Sagas,” Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data
• Microsoft Azure Architecture Center, Saga Design Pattern
• Microsoft, Compensating Transaction pattern
• Microsoft, Asynchronous Request-Reply
• Garcia-Molina and Salem, Sagas (SIGMOD 1987, pp. 249–259; Cornell-hosted paper)