Saga Pattern

In a single database you can wrap several writes in one ACID transaction and roll the whole thing back if anything fails. Once your data is spread across separate services, each with its own database, that trick stops working. There is no shared transaction that can lock rows in the order service, the payment service, and the inventory service all at once.

A saga solves this by turning one big transaction into a chain of small local transactions. Each service does its own piece, commits it immediately, and then hands off to the next service. A travel booking saga might be: reserve flight, then charge card, then reserve hotel. Each step is fully committed in its own service before the next one starts.

Because there is no global rollback, every step that can change data must also define a compensating transaction that semantically undoes it. Cancel the flight reservation, refund the card, release the hotel room. If step 3 fails, the saga walks backward and runs the compensations for steps 2 and 1. The system ends up consistent again, just not instantly.

There are two common ways to coordinate the steps. Choreography is event-driven and has no central brain: each service listens for events on a message broker like Kafka or RabbitMQ, does its work, and emits a new event that the next service reacts to. It is loosely coupled and easy to start with, but the overall flow is implicit and hard to trace once you have more than three or four steps.

Orchestration uses a central coordinator, often called a saga orchestrator, that tells each service what to do and waits for the reply. The orchestrator holds the saga state machine: which step we are on, what to call next on success, and what compensation to call on failure. Frameworks like Temporal, AWS Step Functions, Camunda, and Axon implement this. The flow is explicit and observable, at the cost of one more moving part.

Either way, two properties are non-negotiable. Steps and their compensations must be idempotent, because the broker will redeliver messages and the orchestrator will retry after crashes, so running the same step twice must not double-charge a card. The saga state must also be persisted durably after each step, so a crash mid-saga can be recovered and resumed rather than left half-finished.

Reach for a saga when one user action must update several services and you cannot or do not want a distributed two-phase commit, which holds locks across services and kills availability. Order checkout, money transfers between accounts, and multi-step provisioning are the classic cases.

The big trade-off is that you give up isolation. A saga is not atomic from an outside observer's point of view. Halfway through, other reads can see the flight booked but the card not yet charged. You have to design for these intermediate states, often with a pending or reserved status, and accept dirty reads or use semantic locks to guard against them.

Compensations are also harder than they look. Some actions cannot be cleanly undone. You cannot un-send an email or un-ship a package, so the compensation becomes a counter-action like sending an apology or issuing a return label. If a compensation itself fails, you usually retry it forever and alert a human, because a saga must eventually reach either fully committed or fully compensated. There is no in-between resting state.

Picture an e-commerce checkout built as four services. The Order service creates an order in PENDING state. The Payment service charges the customer. The Inventory service decrements stock. The Shipping service schedules a delivery. Each writes to its own database and emits an event.

Now suppose payment succeeds and stock is decremented, but the Shipping service reports the address is undeliverable. The saga triggers compensations in reverse: Inventory adds the stock back, Payment issues a refund, and Order moves to CANCELLED. The customer sees a clean cancellation and a refund, even though three different databases were touched along the way.

Compare that to the failure mode without compensations: money taken, stock removed, no shipment, and an angry customer. The saga's job is to guarantee that the business outcome is all-or-nothing even though the data writes were not. That guarantee is eventual, measured in seconds to minutes, not the millisecond atomicity of a single-database transaction.