Saga Pattern

In this decentralized coordination style, each service in the saga publishes an event after completing its local transaction. Other services listen for these events and trigger their own local transactions or compensating actions. This creates a loosely coupled workflow without a central orchestrator.

• Key Benefit: High scalability and autonomy for services.
• Challenge: Can become complex to debug as the control flow is distributed across event logs.
• Example: An order service publishes an OrderCreated event, which triggers an inventory service to reserve stock, which then publishes an InventoryReserved event.

In this centralized approach, a dedicated orchestrator service manages the entire saga's execution. It invokes participant services in a defined sequence and, based on their responses, decides whether to proceed with the next transaction or initiate compensating transactions (rollbacks).

• Key Benefit: Simplified business logic and centralized control, making the workflow easier to understand and monitor.
• Challenge: The orchestrator becomes a potential single point of failure and a bottleneck.
• Example: A ShippingOrchestrator service directly calls the Payment, Inventory, and Logistics services in order, managing all rollback logic.

This is the core mechanism for achieving eventual consistency without distributed locks. For every forward operation in the saga, a corresponding compensating transaction is defined. If a step fails, the orchestrator or choreography executes these compensations in reverse order to semantically undo the completed work.

• Crucial Note: Compensations are not simple database rollbacks; they are application-level operations that reverse the business effect (e.g., CancelReservation instead of DELETE).
• Example: If charging a credit card succeeds but shipping fails, the saga executes a RefundPayment compensating transaction.

The Saga Pattern explicitly trades strong consistency (immediate, system-wide data uniformity) for eventual consistency. During saga execution, the overall system state may be temporarily inconsistent (e.g., payment taken but item not yet shipped). The pattern guarantees that the system will converge to a consistent state once all forward operations and any necessary compensations complete.

• Implication: Application logic must be designed to handle these temporary, intermediate states gracefully.
• Contrast: Unlike the Two-Phase Commit (2PC) protocol, which uses locks for strong consistency, sagas avoid locking resources across services for long periods.

A critical requirement for implementing robust sagas. Because network calls can fail and be retried, every transaction and compensating transaction in a saga must be idempotent. Executing the same operation multiple times must have the same final effect as executing it once.

• Implementation: Typically achieved using unique idempotency keys passed with each request, allowing the receiving service to detect and ignore duplicate executions.
• Example: A DebitAccount transaction should check an idempotency key to ensure the same $100 is not withdrawn twice if a request is retried.

The Saga Pattern exists within a broader ecosystem of resilience and transaction management patterns.

• Circuit Breaker Pattern: Often used within a saga step to prevent cascading failures when calling a failing service.
• Retry Policy & Exponential Backoff: Essential for handling transient failures when invoking saga participants.
• Dead Letter Queue (DLQ): Used to store saga events or commands that repeatedly fail for manual investigation.
• Two-Phase Commit (2PC): The primary alternative. Sagas are preferred in long-running business processes across polyglot services, while 2PC is used for short, atomic transactions within tightly coupled systems.

A classic saga orchestrates the steps of an online purchase. The saga begins with an Order Service creating a pending order. Subsequent steps include:

• Inventory Service: Reserves the item.
• Payment Service: Charges the customer's card.
• Shipping Service: Creates a shipment label.

If the payment fails, the saga executes compensating transactions: it releases the inventory reservation and cancels the pending order, ensuring no item is held without payment.

Booking a trip involves coordinating multiple independent providers. A saga manages the process:

1. Flight Service: Reserves a seat.
2. Hotel Service: Books a room.
3. Car Rental Service: Holds a vehicle.

If the hotel is unavailable, the saga triggers compensating actions in reverse order: cancels the car hold and releases the flight reservation. This prevents a customer from being stuck with partial, unusable bookings.

Two primary implementation styles exist:

Orchestration (Centralized): A central Saga Orchestrator (a dedicated service) dictates the flow. It invokes participants in sequence and manages compensation if a step fails. This provides clear workflow control and centralized logic.

Choreography (Decentralized): Participants communicate via events. Each service listens for events, performs its local transaction, and publishes the next event or a compensating event. This increases autonomy but can make the overall flow harder to trace and debug.

The core of the pattern is the compensating transaction—a business action that semantically undoes a previously committed local transaction. Key principles:

• Idempotent: Executing a compensation multiple times must have the same effect as executing it once.
• Commutative: The order of compensation for parallel saga steps should not affect the final state.
• Business-Level Undo: It's not a database rollback. For example, 'Cancel Reservation' is a compensation for 'Create Reservation'; it doesn't delete the original reservation record but updates its status.

In Heterogeneous Fleet Orchestration, a saga can manage a complex material handling task. Example: transporting an item from receiving to storage.

1. Allocate Robot: Assigns an Autonomous Mobile Robot (AMR).
2. Secure Item: Commands a robotic arm to lift the pallet.
3. Navigate to Bin: Plans and executes the route.

If the AMR's battery drops below a threshold mid-route (a failure), the saga executes compensation: it commands the AMR to safely park, releases the item if secured, and updates the central task pool so another agent can be assigned. This maintains system consistency.

Sagas must be resilient to network timeouts and duplicate messages. Critical practices include:

• Idempotent Operations: Each participant's transaction must be safely repeatable. Using an Idempotency Key (e.g., saga_id + step_number) prevents double-charging a credit card.
• Persistence: The orchestrator must persist the saga's state and current step before calling each participant. This allows recovery after a crash.
• Timeouts & Retries: Each step needs a timeout. The orchestrator uses a Retry Policy with Exponential Backoff for transient failures but must eventually fail the saga and trigger compensation.

A resilience pattern that detects failures and prevents an application from repeatedly attempting an operation that is likely to fail. It functions like an electrical circuit breaker, moving between closed, open, and half-open states to allow a failing service time to recover. This prevents cascading failures and resource exhaustion.

• Closed: Requests flow normally.
• Open: Requests fail immediately without attempting the operation.
• Half-Open: A limited number of test requests are allowed to probe for recovery.

A Retry Policy defines the conditions (e.g., which error types) and mechanisms for reattempting a failed operation. Exponential Backoff is a critical algorithm within such policies that progressively increases the wait time between retries (e.g., 1s, 2s, 4s, 8s).

• Purpose: To handle transient faults like network timeouts.
• Key Benefit: Prevents overwhelming a recovering service with immediate retry storms.
• Implementation: Often includes a jitter (random delay) to prevent synchronized retries from multiple clients.

A persistent storage queue for messages or tasks that cannot be processed successfully after all retry attempts. It acts as a quarantine zone for failures, enabling asynchronous error handling.

• Primary Use: In message-driven and event-sourcing architectures.
• Benefit: Prevents a single poisoned message from blocking the entire processing queue.
• Operational Process: Messages in the DLQ can be inspected, repaired, and manually or automatically re-injected for processing.

A pattern that isolates elements of an application into pools, so a failure in one pool does not drain all resources and cause a system-wide failure. Inspired by ship bulkheads that contain flooding.

• Resource Isolation: Applies to thread pools, database connections, or memory allocation.
• Example: A service calling three downstream APIs might use three separate connection pools. If API-1 fails and exhausts its pool, calls to API-2 and API-3 remain unaffected.
• Contrast with Saga: While Saga manages transactional consistency, Bulkhead manages resource failure containment.

The property of an operation whereby it can be applied multiple times without changing the result beyond the initial application. This is critical for safe retries in distributed systems.

• Idempotency Key: A unique identifier (e.g., UUID) sent with a request. The server uses it to recognize and deduplicate repeat requests.
• Saga Relevance: Compensating transactions in a Saga must be idempotent, as the rollback command for a step may be retried. A non-idempotent compensation could over-correct or cause errors.

A coordinated atomic commitment protocol for distributed transactions, often contrasted with the Saga pattern's decentralized approach.

• Phase 1 (Prepare): The coordinator asks all participants if they can commit.
• Phase 2 (Commit/Rollback): If all vote 'yes', the coordinator instructs a commit; otherwise, it instructs a rollback.
• Key Difference vs. Saga: 2PC uses blocking locks during the prepare phase, leading to lower availability. Sagas use local commits and compensating transactions, offering better scalability and availability at the cost of eventual consistency.