How a business outcome stays coherent across separate data owners.
Saga.
A business transaction, several local commits. Plan what happens when a step fails.
Change one thing at a time.
The interesting part is usually why it moved.
A checkout is only as complete as its last local transaction.
Start an order, reserve stock, then try authorizing payment.
This example assumes stock release succeeds. Real compensation must be durable, idempotent and recoverable too.
An order crosses independently owned stores. Payment can fail after stock has already been reserved.
This lab uses an orchestrated checkout with compensable reservations. Local commits are visible before the whole workflow finishes.
A saga is what you reach for once a single transaction is genuinely impossible — because the data has separate owners. It does not give you back the guarantees you lost; it replaces them with business behaviour you now have to design, test and operate. If one database could still hold the whole workflow, that is almost always the better answer.
What this buys, and what it charges you for.
ResilienceHigher is preferable↑ 47
An explicit compensation path releases this failed order’s reservation.
CouplingLower is preferable↓ 31
Stores remain independent, but participants still share workflow contracts.
ConsistencyHigher is preferable↓ 43
Local transactions commit separately. Other operations can observe intermediate states.
Operational complexityLower is preferable↑ 52
Operators need correlation, resumable workflows and tools for failed compensation.
Illustrative scores for this scenario, on a 0–100 scale. They express a direction of change, not a benchmark. Your constraints can change the result. Select a quality to explore the reasoning.
+ What improves
- Coordinate a workflow across independent stores.
- Make business recovery explicit.
± What gets harder
- Compensation is a new business action, not an ACID rollback.
- Intermediate states are visible; isolation needs separate design.
- A saga gives up the I in ACID. Other operations can read partial results, so anomalies have to be handled with deliberate countermeasures rather than assumed away.
Where the edges are.
A pattern is only useful once you know where it stops working. These are the boundaries worth knowing before you commit to it.
When it earns its place
- A long-running workflow spans stores and accepts temporary inconsistency.
When to leave it out
- A single database transaction fits, or partial effects are unacceptable.
New ways to fail
- Compensation can fail and require intervention.
- Duplicate delivery can repeat a charge without idempotency.
Operating the pattern
- Persist workflow state; monitor stuck steps and failed compensation.
The people behind the system
- Teams must own recovery contracts as carefully as success contracts.
Other directions to consider
- A local ACID transaction
- Reservation and confirmation
- Two-phase commit where supported