Reliability · Established
Saga / Compensation
Also known as: Saga pattern, Compensating transaction
A saga splits a business transaction that spans several services into a sequence of local transactions, each paired with a compensating action that semantically undoes it if a later step fails.
01Problem it solves
A single ACID transaction cannot span independent services or third-party APIs. Without a plan for partial failure, a booking can charge a card but never reserve the seat, leaving the system inconsistent.
02Use when / Avoid when
Use when
- One business operation writes to several services that each own their data.
- Two-phase commit is unavailable, too slow or crosses organisational boundaries.
- Every step has a meaningful business-level undo (refund, release, cancel).
- Temporary inconsistency between steps is acceptable to the business.
Avoid when
- All writes live in one database that already supports a local transaction.
- A step is irreversible and has no acceptable compensation (e.g. a sent physical shipment with no return flow).
- Readers must never observe intermediate state and you cannot add isolation countermeasures.
03How it works
- 1StepExecute local transaction T1 and record that compensation C1 is now owed.
- 2AdvanceContinue with T2 … Tn, registering each compensation as its step commits.
- 3FailIf Tk fails, stop forward progress.
- 4CompensateRun Ck-1 … C1 in reverse order; compensations are retried until they succeed.
- 5SettleThe saga ends either fully committed or fully compensated.
04Capabilities
| Capability | What it means |
|---|---|
| Compensating actions | Each completed step has a declared undo action that is run in reverse order when a later step fails. |
| Automatic retries | Failed steps are re-attempted according to a declared policy (attempts, backoff, retryable errors) rather than ad hoc code. |
| Persistent execution state | Progress, variables and position in the workflow are stored outside process memory, so a crash does not lose where execution was. |
05Tradeoffs
| Aspect | You gain | You pay |
|---|---|---|
| Consistency | Eventual consistency across services without distributed locks. | No isolation: other transactions can see intermediate state. |
| Design effort | Explicit, auditable failure handling per step. | Every step needs a designed, tested compensation. |
| Coordination style | Can be orchestrated centrally or choreographed through events. | Choreographed sagas are hard to trace; orchestrated sagas add a coordinator. |
06Failure considerations
| Failure mode | Mitigation |
|---|---|
| A compensation itself fails and leaves the system half-rolled-back. | Make compensations idempotent and retry them durably; escalate to a human queue after a bound. |
| Concurrent sagas act on intermediate state (lost updates, dirty reads). | Use semantic locks, pending states or commutative updates for affected records. |
| The coordinator crashes mid-saga and forgets which compensations are owed. | Run the saga on durable execution or persist the saga log before each step. |
07Implementations
Examples of products and frameworks that implement this pattern. Listed as evidence, not endorsement.
| Implementation | Mechanism |
|---|---|
| TemporalDurable execution engine | Compensations are registered in workflow code and executed on failure. |
| AWS Step FunctionsCloud workflow service | Catch branches invoke compensating steps. |
| RestateDurable execution engine | Compensations are written in handler code and run durably on failure. |
| CamundaProcess orchestration (BPMN) engine | BPMN compensation events trigger compensation handlers. |