Saga
A saga connects several local transactions into a business flow. Failures are treated by explicitly designed compensations.
- Local stepEach service writes for itself.
- FailureThe result is a technical signal.
- CompensationReverse technically.
Context
Why this is important
There is no common transaction across multiple services. If one step fails, the previous one remains if you do not explicitly undo it. The individual atomic boundary is its own building block.
This building block explains distributed business flows and compensation. For a single atomic boundary, see Transaction Limits.
At a glance · Saga with compensation
Order saga in case of failure
Variant: Warehouse and payment run as separate services, because independent operation was technically justified. Order coordinates the reservation and the externally connected payment provider.
This is how you read the picture
- Local step The warehouse declares "reservation" R-77 Then, “payment is made,” and “payment is made.”
- Failure In the case of “Payment refused”, the payment service shows “no charge” and the order receives the signal.
- Compensation With Saga, the order sends "R-"77 release" and the camp shows "R-77 released.
- runningOrderFlow complete
- runningStorage servicesReservation R-77 Combined
- runningPayment servicePayments under the Loan
- runningShipping serviceSupply contract created
NoneOpen resettlement
All local steps succeed. Without errors, the flow does not need compensation.
Benefits & limitations
Helps if:
- A Saga tracks shared process progress and follow-up actions across local transactions.
- A compensation permitted by business rules defines how to offset an earlier effect.
- A permanent process status enables continuation and clarification across restarts.
Boundaries
- Irreversible effects, such as goods already shipped, cannot simply be compensated and need a business resolution process.
- Compensation can also fail. Save the state of the saga so that it can be repeated or cleared by hand.
- A process contained within one atomic boundary needs only a transaction; see Transaction Boundaries.
In practice
- Define steps, owners and durable intermediate states. Each participant commits locally; after a restart, the coordinator resumes from recorded progress.
- Define compensations as separate business actions and verify that they are permitted. Failed compensation needs a visible resolution path.
- Monitor status, retries and manual intervention for each operation. Orchestration & Choreography explores control styles; Idempotency covers safe retries.
Read the detailed explanation
A Saga coordinates local transactions across participants. A process records progress and determines follow-up actions. A compensation is a new business action that offsets an earlier effect; the original operation remains in the history.
Orchestration centralises control; choreography distributes reactions through events. Both need durable states, identifiers and resumption rules. Compensation depends on business consistency requirements; effects that cannot be compensated need an explicit resolution state.
Orchestration explains who controls progress; Idempotency associates retries with the same local effect. Compensation remains a business decision.
The pivot step (Point of No Return) marks the transition to completing the process forwards rather than compensating earlier steps. In the shop, this is typically the charge at the payment provider. Earlier steps are compensable; later steps are retryable with Idempotency. A compensation is also called a Compensating Transaction.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What remains bound in case of rejected payment without compensation?
View the solution with justification
The reservation R-77 in warehousing.
ApplyingTransferred to a new situation
The payment is accepted, but before that the reservation failed. What is true of the saga?
View the solution with justification
There would be no reservation to take back; a payment should not even be ordered before R-77 is present. In the picture, the payment follows the reservation confirmation.
EvaluateWeighing an alternative
Would a global transaction via warehouse and payment be easier than a saga? How do you weigh up?
View the solution with justification
It would be easier to think of, but tie independently operated services closely together. The saga keeps them separate, demanding compensation such as “R-”77 release.
Explore further
These building blocks continue the thoughts of this page.