Saga Pattern: Consistent Updates Across Systems

Some business actions touch several systems at once. Converting a won deal might create a customer in accounting, reserve stock in an inventory system and open a project in a delivery tool. If the third step fails, what happens to the first two? Inside one database, a transaction would roll everything back. Across separate systems, there is no shared transaction to roll back, and you can end up with a customer and a stock reservation for a project that does not exist. The saga pattern is a way to keep multi-system updates consistent without one big transaction. This guide explains how sagas work, the two ways to coordinate them, what compensating actions involve and when the pattern is worth its complexity.

Why one transaction is not an option

Separate systems each have their own data store, and many are third-party products you cannot enrol in a distributed transaction. The microservices.io description of the saga pattern starts from this constraint: two-phase commit is not an option for transactions that span services (microservices.io: Saga). Even where it is technically possible, holding locks across several systems while waiting for all of them couples them tightly and makes each one only as available as the slowest.

How the saga pattern works

The same page defines a saga as a sequence of local transactions. Each local transaction updates one system and then publishes a message or event that triggers the next step. If a step fails because it violates a business rule, the saga runs a series of compensating transactions that undo the changes made by the earlier steps.

For the deal conversion example:

1. Create the customer in accounting.
2. Reserve stock in inventory.
3. Open the project in the delivery tool.

If step 3 fails, compensations run in reverse: release the stock reservation, then deactivate or flag the customer record. Each system stays internally consistent, and the overall business action either completes or is cleanly undone.

Choreography or orchestration

The microservices.io page describes two ways to coordinate a saga:

• Choreography: each local transaction publishes events that trigger local transactions in other services. There is no central controller; each participant knows what to do when it sees certain events
• Orchestration: an orchestrator tells the participants which local transactions to execute, and tracks progress

Choreography suits short sagas with few steps, where the flow is simple to follow. As steps multiply, the flow becomes spread across many services and hard to understand. Orchestration puts the whole flow in one place, which makes it easier to see the current state of each saga, add steps and handle failures, at the cost of an extra component to build and run. For integrations between business applications, where the "services" are often SaaS products that cannot hold saga logic themselves, an orchestrator in your integration layer is often the practical choice.

Design compensating actions

The page lists lack of automatic rollback as a drawback: developers must design compensating transactions that explicitly undo earlier changes, rather than relying on a database rollback. Compensation is a business decision as much as a technical one:

• Some actions can be reversed directly, such as releasing a reservation
• Some can only be counteracted, such as issuing a credit note rather than deleting an invoice
• Some cannot be undone at all, such as an email already sent to a customer

Order steps so that the hardest to undo come last. Send the welcome email only after every other step has succeeded. Where an action cannot be undone, design the follow-up, such as a correction message, before you need it.

Make every step idempotent

Messages can be delivered more than once and steps can be retried after timeouts. Each step and each compensation must be safe to repeat: creating a customer that already exists for this saga should return the existing one, and releasing a reservation that is already released should do nothing. Give every saga an ID and pass it to each step, so participants can recognise repeats. The page also notes that each service must atomically update its database and publish a message, which is what our guide to the outbox pattern addresses.

Handle the lack of isolation

The microservices.io page names lack of isolation as the second drawback: while a saga is in progress, other processes can see its partial results, which risks data anomalies when sagas and transactions run concurrently. In the example, a stock report might count the reservation before the project exists. Countermeasures include marking records as pending until the saga completes, checking state again before each step and designing reads to ignore records in a pending state.

Worked example: a hypothetical saga design

The table below sketches a hypothetical orchestrated saga for converting a won deal. It shows how steps, compensations and states fit together, not a tested design.

StepSystemActionCompensationState while running1AccountingCreate or link customerFlag customer as inactive if created by this sagaPending2InventoryReserve stock for deal itemsRelease reservationPending3Delivery toolOpen project from templateArchive projectPending4CRMMark deal as converted, link recordsRevert deal statusPending5EmailSend welcome emailNone possible; send correction if neededComplete after send

Report saga status clearly

A saga is asynchronous, so the person who triggered it needs to know the outcome. The page discusses options such as responding once the saga completes or responding immediately with an ID the client can use to check progress. In business applications, showing a status on the record, such as converting, converted or conversion failed with a reason, works well. Alert an owner when a saga fails and its compensation also fails, because those cases need a person. Keep a log of every saga with its steps, timings and outcome, so recurring failures at the same step are easy to spot and fix at the source.

Know when not to use a saga

Sagas add design and operational effort. If a failure can be fixed by a simple retry later, or a person can resolve the occasional inconsistency from a report, a scheduled reconciliation may be enough. Consider a saga when partial failures are costly, frequent enough to matter or hard to spot. Our guide to microservices communication patterns covers the messaging choices that sagas build on.

Frequently Asked Questions

What is the saga pattern?

A way to keep updates across several systems consistent by running a sequence of local transactions, with compensating transactions that undo earlier steps if a later one fails.

What is the difference between choreography and orchestration?

In choreography, participants react to each other's events with no central controller. In orchestration, a coordinator tells each participant what to do and tracks progress.

What is a compensating transaction?

An action that undoes or counteracts an earlier step, such as releasing a reservation or issuing a credit note.

Do sagas provide isolation like database transactions?

No. Other processes can see partial results while a saga runs, so designs often mark records as pending until the saga completes.

Keep multi-system updates consistent

We design orchestrated workflows across CRMs, accounting and operational systems, with compensations, idempotent steps and clear status. See our real-time CRM and database synchronization service, or talk to us about the saga pattern.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.