Split the business transaction into independently committed local steps.
Reliability & Delivery · Distributed Consistency
Saga
Break a distributed transaction into local transactions connected by commands or events. Each completed step has a compensating action so failures can be recovered without a global database transaction.
How can a long-running business transaction remain consistent when it spans multiple independent services?GateSift summary based on Microsoft Azure Architecture Center guidance. The wording, visualization, Azure mapping and analyzer context are original GateSift material.
Original GateSift visualization
How Saga works
Local transactions are coordinated as a long-running business process with compensation for failed paths.
Distributed business transaction
Saga coordinator
Completed
Compensated
Coordinate the next command or event while preserving durable saga and correlation state.
Complete all steps or invoke compensating actions to restore a valid business outcome.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use a saga when one business transaction spans independently committed systems and consistency must be achieved through coordinated forward actions and compensation rather than one distributed ACID transaction.
- Multiple services or systems each commit local state as part of one business outcome.
- The process can tolerate temporary intermediate states while the saga progresses.
- Failed later steps have meaningful compensating business actions.
- All required state can be committed atomically inside one local transactional boundary.
- A completed step cannot be compensated and partial completion would be unacceptable.
- The process has no durable identity or state model for tracking progress across long-running steps.
Compensation failureHigh impact
The recovery action is itself distributed work and can fail, requiring escalation and durable retry.
Concurrent sagasHigh impact
Two long-running transactions can observe and modify overlapping business state in surprising orders.
Opaque progressReview
Without explicit saga state, operators cannot tell whether an instance is progressing, waiting or stuck.
- Durable Functions and Logic Apps can coordinate saga state, but compensation logic should remain explicit and testable rather than implicit in generic exception handling.
- Use stable business correlation identifiers and persist the status of each committed step.
- Design idempotency for both forward and compensating operations because either can be retried after uncertain failures.
What this pattern helps you decide
Break a distributed transaction into local transactions connected by commands or events. Each completed step has a compensating action so failures can be recovered without a global database transaction.
Which local transaction commits at each step and what compensates it later?
How is saga progress persisted and correlated across systems?
What happens when a compensation action also fails?
Where you may see it
- Logic Apps or Durable Functions orchestration
- Service Bus commands and events across bounded contexts
- Stateful process managers coordinating local transactions
How the analyzers can surface it
- Long-running workflows with several business side effects
- Compensation paths paired with orchestration state
- Correlation identifiers connecting commands, events and recovery actions
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
Source guidance and attribution
This page links to Microsoft Azure Architecture Center for the source architecture guidance. GateSift summaries, diagrams, Azure examples and analyzer signals are original. No endorsement by Microsoft is implied.