System Design · Architecture under constraints
How does the saga pattern handle long-running business transactions?
Short answer
A saga splits a distributed transaction into local steps with compensating actions. On failure it runs compensations in reverse order, exposing intermediate states that the product must tolerate.
A saga models a business workflow as a sequence of local transactions, each in one service. If a later step fails, the saga runs compensating actions for the steps that already succeeded. It does not roll back in the database sense; it creates new effects that undo the old ones.
Orchestration versus choreography
- Orchestration: a saga coordinator calls each step and records progress, which is easier to observe and retry
- Choreography: services react to events and emit the next event, which has less central coupling but a less visible flow
- Each step must be idempotent because a coordinator or broker may retry it
- Compensations must also be idempotent and should be retried until they succeed
- The saga log is the source of truth for where the workflow is
Some steps cannot be compensated. Sending an email, charging a card or shipping a package may have external effects. For those, the design moves the irreversible step as late as possible, uses a reservation or authorization first, or introduces a manual resolution path. Pretending an email can be unsent is a common design error.
Intermediate states are visible. A customer may see an order in Pending while inventory is reserved and payment is authorized. Use semantic locks, such as a reserved flag, so other operations do not act on the half-finished state. The user interface should show a pending state rather than claiming success.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you compensate an irreversible action?
- 2What is a semantic lock in a saga?
- 3How does an orchestrator know where to resume after a crash?
- 4Why must both steps and compensations be idempotent?
Say it in the interview
A saga breaks a distributed workflow into local transactions and compensates the completed steps when a later one fails. I prefer orchestration when the flow needs visibility and retries, and choreography when the reactions are genuinely independent. Each step and compensation is idempotent, and the saga log is the durable source of progress. Irreversible steps go last or get a reservation, because a compensation is a new action, not a true rollback.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.