G1Joshi Saga Pattern
The Saga pattern manages data consistency across microservices in distributed transaction scenarios. 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.
When to Use
- Distributed Transactions: e.g., "Book Flight" + "Book Hotel" + "Charge Card".
- Long-running processes where you can't hold a DB lock.
- Ensuring eventual consistency across Services A, B, and C.
Core Concepts
Compensating Transactions
If a step fails (e.g., Card Declined), the Saga must execute compensating transactions to undo the changes made by the preceding steps (e.g., "Cancel Hotel", "Cancel Flight").
Choreography
Each service listens to events and decides what to do.
- Order Service ->
OrderCreated - Inventory Service -> listends to
OrderCreated-> does work ->InventoryReserved
Orchestration
A central coordinator (Orchestrator) tells each service what to do.
- Orchestrator -> Call Order Service
- Orchestrator -> Call Inventory Service
- Orchestrator -> Handle failure -> Call Compensation.
Best Practices
Do:
- Prefer Orchestration for complex sagas (easier to visualize and trace).
- Ensure all steps are Idempotent.
- Design for failure (Everything that can fail, will fail).
Don't:
- Don't rely on synchronous HTTP calls for Sagas (What if the network drops in the middle?). Use Message Queues or Persistent Orchestrators (Temporal).
Tools
- Temporal.io: Workflow engine for code-based orchestration.
- MassTransit (C#): Built-in Saga state machines.