Saga Pattern
Practice this topic in a realistic system design interview
Suppose we're building an e-commerce application using microservices. When a customer places an order, several services need to work together:
- The order service creates the order.
- The inventory service reserves the items.
- The payment service charges the customer.
- The shipping service schedules the delivery.
Each service owns its own database, so we can't use a single database transaction to cover the entire operation.
One option is a distributed commit protocol like two-phase commit (2PC). But two-phase commit requires participants to hold locks while waiting for a global decision. This introduces contention and can block transactions when a participant or the coordinator becomes unavailable. It also doesn't work with external systems, like third-party payment providers, that cannot prepare a transaction and wait for a commit decision.
We need another way to coordinate these operations while keeping the system consistent. This is where the Saga pattern comes in.
In this chapter, we will look at how the Saga pattern manages transactions across multiple services, how it handles failures without a distributed transaction, the two main ways to coordinate a saga, and the trade-offs involved.