What is a Saga
A saga is a pattern for managing a business process that spans multiple services, where each service has its own database and there is no shared transaction boundary. Instead of one ACID transaction, a saga is a sequence of local transactions, each with a compensating action that undoes it if a later step fails.
How it works
Consider placing an order:
- Order service creates the order (compensating action: cancel the order).
- Payment service charges the card (compensating action: refund the charge).
- Inventory service reserves stock (compensating action: release the reservation).
If step 3 fails (out of stock), the saga runs compensating actions in reverse: refund the payment, then cancel the order.
Two coordination patterns:
Choreography — each service listens for events and decides what to do next. The order service emits OrderCreated, the payment service reacts, and so on. Simple but hard to trace and debug as the number of steps grows.
Orchestration — a central orchestrator tells each service what to do and handles the compensation logic. Easier to understand and monitor, but the orchestrator is a single point of coordination.
Why it matters
In a microservices architecture, each service owns its data. There is no single database to wrap a distributed operation in a transaction. Sagas provide eventual consistency across services while keeping each service autonomous.
The tradeoff: sagas are more complex than ACID transactions, compensation logic must be written and tested for every step, and the system is temporarily inconsistent between steps.
For distributed transaction patterns, see How Distributed Transactions Work.