The saga pattern is a way to keep data consistent when one business transaction spans several services, each with its own database. Instead of one big ACID transaction, a saga runs a sequence of local transactions. If a step fails, the saga may run compensating transactions to counteract earlier completed steps, where those steps are compensable. You trade immediate consistency for eventual consistency, and you pay for it in design effort.
This guide is written for CTOs, integration managers and the executives who sign off the budget. It explains how sagas work, how to choose between orchestration and choreography, what goes wrong in production, and where enterprise integration platforms fit.
Key takeaways
- A saga replaces a distributed ACID transaction with a chain of local transactions plus compensations, giving eventual consistency rather than instant consistency.
- Choreography suits short, simple flows. Orchestration suits long-running, mission-critical processes where you need to see and control state.
- The hard part is not the happy path. It is idempotent compensations, reliable event delivery and observability.
- Saga logic needs a dependable messaging and integration backbone, so the platform decision matters as much as the pattern.
- If your flow is simple or sits inside one database, you may not need a saga at all.
Table of Contents
- What the saga pattern is
- Why not simply use a distributed transaction?
- A worked example: an order across four services
- Orchestration or choreography
- What actually goes wrong in production
- Sagas, events and CQRS
- Where integration platforms fit
- Our perspective
- When you may not need a saga
- A short checklist before you build
- Talk to us about your integration estate
- FAQ
- Sources
What the saga pattern is
The pattern applies once you have adopted database per service. Each service owns its data, so a business transaction that touches several services can no longer rely on a single database commit. The microservices.io description of the pattern frames a saga as a sequence of local transactions, where each one updates its own service and triggers the next. When a step fails, compensating transactions counteract earlier changes where possible; they do not necessarily restore the exact prior state.
The idea is older than microservices. It comes from a 1987 paper by Garcia-Molina and Salem on long-lived transactions, where a saga was a sequence of operations that can be interleaved with other work, with compensating actions defined for recovery. That is also the answer to why it is called a saga: it models a long story made of many smaller episodes rather than one atomic event.
Why not simply use a distributed transaction?
The classic alternative is two-phase commit (2PC), an atomic commit protocol rather than a consensus protocol. Its locking behaviour makes it awkward for reactive, loosely coupled systems. Locks held across network calls mean one slow participant can stall everyone else. Some modern data stores and message brokers do not support it at all.
Sagas avoid cross-service locks. Each service commits locally and moves on. The price is that, for a short time, the overall system can be in an in-between state: stock reserved but payment not yet taken, for example. Your business needs to be comfortable with that, and your design needs to make those states safe.
This is the key point for decision makers: a saga is not a drop-in replacement for ACID. It is a different contract.
A worked example: an order across four services
Take an order flow in a retailer or logistics business with four services: Orders, Payments, Inventory and Shipping.
| Step | Local transaction | Compensation if a later step fails |
|---|---|---|
| 1. Orders | Create order in a pending state | Mark order as cancelled |
| 2. Inventory | Reserve stock | Release reservation |
| 3. Payments | Take payment | Refund payment |
| 4. Shipping | Book shipment | Cancel booking |
If Payments declines the card at step 3, the saga does not roll back a database. It tells Inventory to release the reservation and tells Orders to mark the order cancelled. Each compensation is a real business action, with its own failure modes, audit trail and sometimes customer communication.
Note that compensation is not always a perfect undo. A refund is not the same as never having charged the customer. Your design should treat compensations as first-class business operations, reviewed by the people who own the process, not only by engineers.
Compensable, pivot and retryable steps
The Azure Architecture Center gives a useful vocabulary. Compensable transactions can be undone. A pivot transaction is the point of no return: once it succeeds, the saga must go forward to completion. Retryable transactions come after the pivot, are idempotent, and are retried until the saga reaches a consistent end state.
In the example above, taking payment might be the pivot. Before it, you can cancel freely. If payment is defined as the pivot, subsequent actions must be designed to reach a valid terminal state through retries or explicit exception handling. Whether payment should be the pivot depends on refund and fulfilment policies. Deciding where the pivot sits is a business decision as much as a technical one.
Orchestration or choreography
There are two ways to coordinate a saga. In choreography, participants exchange events and each service decides what to do next. In orchestration, a central coordinator tells each participant what to do and tracks the outcome.
| Criterion | Choreography | Orchestration |
|---|---|---|
| Control | Decentralised, no single owner | Central orchestrator owns the flow |
| Best for | Few steps, low coupling | Long-running, mission-critical processes |
| Visibility | Flow is implicit, spread across services | Flow and state in one place |
| Debugging | Harder as services multiply | Easier, one timeline per saga |
| Coupling risk | Cyclic dependencies between services | Orchestrator can become a bottleneck if overloaded with logic |
| Change | Touching the flow means touching several services | Change mostly in the orchestrator |
The guidance from microservices.io is consistent with what most architects see: choreography is simple and decentralised for small workflows, but becomes hard to manage as complexity grows. Teams then move to orchestration to observe state, debug failures and avoid cyclic dependencies. An IEEE paper comparing the two approaches exists for those who want an academic treatment.
A practical rule of thumb
- For a small number of participants managed by one team, consider choreography if event dependencies remain easy to understand and observe.
- For many participants, multiple teams, or audited processes, favour orchestration when centralised visibility and control justify the additional coordination component.
- Mixed estates: orchestrate the critical business process and let low-risk side effects, such as notifications, react to events.
Choreography is not wrong. It just gives you no single place to answer the question every executive eventually asks: where is this order, and why is it stuck?
What actually goes wrong in production
Compensations that are not idempotent
Messages can be delivered more than once and compensations can themselves fail. If refunding twice is possible, you will eventually refund twice. Every compensating action and every retryable step must be safe to repeat. Experienced practitioners find that designing reliable compensations is harder than building the forward flow.
Dual writes
A service that updates its database and then publishes an event risks an inconsistent dual-write outcome unless it uses an appropriate coordination mechanism. Crash between them and the saga stalls, or the world moves on without the database knowing. The usual remedy is the outbox pattern: write the event to an outbox table in the same local transaction, then relay it to the broker. The InfoQ article on saga orchestration with the outbox pattern walks through this, including the use of change data capture tooling.
No visibility
A saga that fails halfway and nobody notices is worse than one that fails loudly. Give every saga a correlation ID, record its state, alert on sagas that stay in a state too long, and give operations a way to intervene manually. This is the strongest practical argument for orchestration.
Isolation anomalies
Because sagas lack the isolation of ACID transactions, other transactions can see intermediate data. Countermeasures include marking records as pending, using semantic locks and ordering steps so the riskiest ones come first. The Azure guidance covers these trade-offs in more detail.
Sagas, events and CQRS
Sagas are not inherently tied to CQRS, but the two often appear together in event-driven systems. CQRS separates the write model, where sagas often operate to preserve integrity, from the read model, which can be optimised and scaled independently. Event-driven design more broadly shifts work from explicit synchronous calls to asynchronous events, which can improve resilience because services process messages at their own pace.
There is a business benefit too. An early article on the event-command-saga approach describes it as a more agile way to implement workflows, since it does not need a big design in place before coding starts. Workflows map to message flows that business stakeholders can read.
Where integration platforms fit
Most enterprises do not build sagas on green fields. They run them across ERP, core banking, billing, logistics and customer systems, some of which are decades old and cannot take part in a modern event flow without help. That is where an integration layer earns its keep.
The pieces of a saga map onto platform capabilities you may already own:
- Event backbone. A broker or event mesh carries the events that trigger steps and compensations. Solace is a common choice for high-volume, event-driven estates.
- Orchestration and flow control. Boomi, MuleSoft and TIBCO offer integration and workflow capabilities that can support saga coordination, error handling and compensating calls, depending on product and implementation choices.
- API and adapter layer. Legacy systems that cannot publish events are wrapped with APIs or connectors so they can act as saga participants.
- Monitoring. Whatever coordinates the saga should expose its state to operations teams.
Polarising works with Boomi, MuleSoft, TIBCO and Solace as part of enterprise integration, and you can see the platforms we cover on our integration platforms page. The right choice depends on what you have licensed, your team’s skills and your throughput needs, not on which logo is fashionable. Our event-driven architecture services cover the messaging side, and the broader enterprise integration practice covers the API and orchestration side.
If you run telecom estates, our guide to BSS and OSS integration shows why long order-to-activate flows are a natural fit for orchestrated sagas.
Our perspective
A recurring architectural risk in enterprise programmes is that teams adopt microservices or event streaming, encounter cross-service consistency challenges and choose choreography for its apparent simplicity. As workflows expand, tracing a stalled transaction across multiple services can become operationally expensive.
Our view is that governance and accountability should be designed in from the start, not retrofitted. For a saga, that means three things. First, name an owner for each business process and agree its compensations with the business. Second, make state visible: if you cannot see a saga, you cannot be accountable for it. Third, treat the legacy systems as first-class participants. In legacy-heavy estates, the saga is rarely the hard part. The hard part is getting a thirty-year-old system to behave predictably when asked to undo something.
Polarising brings together senior nearshore teams in the UK and Portugal and works across sectors including finance, healthcare and telecommunications. These problems reward experience, because the failure modes are rarely in the textbook.
— Polarising Team
When you may not need a saga
Sagas add moving parts. Before adopting one, check these alternatives:
- Merge the services. If two services always change together and share a transaction, they may be one service. Splitting them created the problem.
- Single-database transactions. Inside one bounded context, ordinary ACID is simpler and safer.
- Accept inconsistency with reconciliation. Some low-value flows are better served by a periodic reconciliation job than a full saga.
- Workflow engines. For long-running human-in-the-loop processes, a workflow engine with explicit state may be a better fit than hand-built compensation.
Sagas are most valuable when the process is genuinely distributed, the steps are business-significant, and a stuck or half-complete state has a real cost.
A short checklist before you build
- Map the business process end to end and mark which steps can be undone.
- Choose the pivot transaction and define what happens before and after it.
- Write each compensation as a business operation and make it idempotent.
- Use the outbox pattern, or an equivalent, to avoid dual writes.
- Pick orchestration where the process is critical, long-running or audited.
- Add correlation IDs, state tracking, alerting and a manual intervention path.
- Test failure at every step, including failure of the compensations.
Integration, APIs and architecture, including enterprise orchestration and governed automation.
Talk to us about your integration estate
If you are designing sagas across a mix of modern services and legacy platforms, we can help with the architecture, the integration platform and the delivery team. Start with our enterprise integration services, or see how AI Pods can add senior, AI-accelerated delivery capacity to your programme.
FAQ
What is the saga pattern in microservices?
It is a way of managing data consistency across services that each own their database. A business transaction is split into local transactions, each triggering the next. If one fails, compensating transactions undo the earlier steps.
What is the difference between saga orchestration and choreography?
In choreography, services react to each other’s events with no central controller. In orchestration, a central coordinator directs each step and tracks state. Choreography is simpler for small flows, while orchestration gives better visibility and control for complex, long-running ones.
Does the saga pattern replace ACID transactions?
No. It trades immediate consistency for eventual consistency. During a saga, the system can be in an intermediate state, so you must design for that and make compensations idempotent.
How do you implement a saga reliably?
Use local transactions, idempotent steps and compensations, and the outbox pattern to record outgoing events atomically with database changes before publishing them asynchronously. Track state with correlation IDs and monitor for stuck sagas. A message broker or integration platform usually carries the events and calls.
Sources
- Pattern: Saga, microservices.io
- Saga Design Pattern, Azure Architecture Center
- The Saga Pattern in a Reactive Microservices Environment, SciTePress
- Saga Orchestration for Microservices Using the Outbox Pattern, InfoQ
- Comparison of Choreography vs Orchestration Based Saga Patterns, IEEE Xplore
- Event Driven Architecture, Hackney Development System
- Cutting Edge: Event-Command-Saga Approach for Business Logic, Microsoft Learn