The Saga Pattern: Consistency Without Distributed Locks
In a microservices architecture, a single business process (like "Order Placement") often spans multiple services and databases. Since NoSQL databases don't support cross-service transactions, we need the Saga Pattern to ensure eventual consistency.
1. What is a Saga?
A Saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails, the saga executes a series of compensating transactions to undo the changes made by the preceding local transactions.
2. Two Ways to Implementation Sagas
Choreography (Event-Based)
Each service produces and listens to events from other services and decides whether an action should be taken.
- Pros: Simple, loosely coupled, no central point of failure.
- Cons: Hard to understand the entire workflow; risk of cyclic dependencies.
Orchestration (Command-Based)
A central "Orchestrator" (Saga Manager) tells the participants what local transactions to execute.
- Pros: Centralized logic; easier to manage complex workflows; avoids cyclic dependencies.
- Cons: The orchestrator can become a bottleneck or a single point of failure.
3. Handling Failure: Compensating Transactions
A compensating transaction is an operation that "undoes" the effect of a previous transaction.
- Example: If the "Payment Service" fails, the "Inventory Service" must run a compensating transaction to "Un-reserve" the items.
- Note: Compensating transactions must be idempotent because they might be retried multiple times.
4. The ACD (No Isolation) Problem
Sagas provide Atomicity, Consistency, and Durability, but they lack Isolation. Since local transactions are committed immediately, other sagas might see intermediate (and potentially incorrect) data.
- Countermeasures: Use "Semantic Locks" (a field like
state: 'PENDING') to prevent other processes from using data until the saga completes.
5. When to use Sagas?
- Use Sagas for long-lived business processes that span multiple services.
- Avoid Sagas if you can redesign your system to keep the transaction within a single service/database.
Summary
The Saga pattern is the industry standard for maintaining consistency in distributed systems. By breaking a global transaction into a series of local ones with robust error handling, you can build scalable, resilient microservices that handle complex business logic with ease.
