Saga Pattern for Distributed Transactions

In microservices, a single business transaction may span multiple services. The Saga pattern coordinates these multi-step operations.

The Problem

Traditional 2PC (Two-Phase Commit) is slow and locks resources. In microservices with independent DBs, it's not feasible.

Saga Pattern

A Saga is a sequence of local transactions. Each step publishes an event or message to trigger the next. If a step fails, compensating transactions undo previous steps.

Orchestration Saga

A central Saga Orchestrator tells each service what to do.

Saga Orchestrator:
  1. → Order Service: Create Order
  2. → Inventory Service: Reserve Items
  3. → Payment Service: Process Payment
  4. → Shipping Service: Schedule Delivery

On Payment Failure:
  4. → Inventory Service: Release Items
  5. → Order Service: Cancel Order

Choreography Saga

Services react to events — no central coordinator.

OrderCreated → InventoryService (reserve)
InventoryReserved → PaymentService (charge)
PaymentCharged → ShippingService (ship)
PaymentFailed → InventoryService (release)

Orchestration vs Choreography

	Orchestration	Choreography
Complexity	Lower	Higher
Coupling	Central coordinator	Event coupling
Tracing	Easy	Harder
Flexibility	Lower	Higher

Idempotency

All Saga steps must be idempotent — safe to retry:

If payment already processed, return success (don't charge twice)

Conclusion

Saga pattern enables long-running distributed transactions with eventual consistency. Orchestration suits complex workflows; choreography suits event-driven systems.