When building microservices, business transactions often span multiple services. For example, in an e-commerce system:
Order Service → creates and manages orders.
Payment Service → processes payments or holds funds.
Inventory Service → reserves or releases stock.
Shipping Service → arranges delivery.
In a monolithic application, these steps could be wrapped in a single ACID database transaction. If something fails, the transaction rolls back and the database stays consistent. But in microservices, each service has its own database. There’s no global transaction manager. We need another way to keep data consistent across services.
This is where the Saga Pattern comes in.
What is a Saga?
A Saga is a sequence of local transactions in different services. Each transaction updates its service’s data and then triggers the next step. If any step fails, the saga executes compensating transactions to undo the previous steps.
Example: Place an Order
Normal flow (everything works):
1. Order Service → create order (status: pending) 2. Payment Service → reserve money 3. Inventory Service → reserve stock 4. Shipping Service → schedule delivery 5. Order Service → mark order as confirmed
Failure flow (Inventory out of stock):
1. Order Service → create order (status: pending) 2. Payment Service → reserve money 3. Inventory Service → FAIL (out of stock) Compensation steps: → Payment Service → refund money → Order Service → cancel order
At the end, the system is consistent: no money is taken, no inventory is reserved, the order is canceled.
Two Types of Saga
Choreography (Event-Driven)
Each service listens for events and produces its own events.
No central orchestrator; services coordinate by reacting to each other.
Example: Order Service emits OrderCreated → Payment Service reserves payment and emits PaymentReserved → Inventory Service consumes that and reserves stock.
✅ Pros: Simple, no central brain.
❌ Cons: Harder to manage as flows become complex (“event spaghetti”).
Orchestration (Central Coordinator)
A dedicated orchestrator service tells each service what to do.
It knows the whole process: call payment, then inventory, then shipping.
If something fails, the orchestrator calls compensations in reverse order.
✅ Pros: Easier to handle complex workflows, clear visibility.
❌ Cons: Central brain adds coupling; the orchestrator must be reliable.
In Part 2, we’ll move from theory to practice and learn how to implement a Saga in Golang using Temporal.io, complete with code and examples.