Saga Pattern

The Saga pattern abandons strong, immediate ACID consistency in favor of eventual consistency. Instead of a single atomic transaction, it sequences local commits. If a failure occurs, compensating transactions are executed to roll back the completed steps, ensuring the system reaches a semantically correct state, though not necessarily the original one. This trade-off is essential for high availability in distributed, microservices-based systems where locking resources for extended periods is impractical.

Each local transaction within a Saga must have a predefined compensating transaction (or undo operation). This is not a traditional database rollback but a semantic reversal of the business operation. For example:

• If a step Reserve Inventory succeeds, its compensation is Release Inventory.
• If Charge Credit Card succeeds, compensation is Issue Refund. These compensations are idempotent and must be designed to handle being called multiple times due to retries. The pattern's reliability hinges on the correct design and execution of these compensating actions.

Sagas are implemented via two primary coordination styles:

• Orchestration: A central Saga orchestrator (a stateful service or workflow engine) dictates the sequence of steps and manages failures by invoking compensations. This provides clear control flow and centralized logic but introduces a single point of management.
• Choreography: Each service publishes events after completing its local transaction. Other services listen for these events and react, triggering their local transactions or compensations. This is more decoupled but can lead to complex, hard-to-debug "event spaghetti" and makes monitoring the overall saga state more difficult.

The core value of the Saga pattern is its structured approach to partial failures. When a step fails, the system executes a backward recovery process by triggering the compensations for all previously completed steps in reverse order. This requires:

• Persistence of Saga State: The progress and outcome of each step must be durably logged.
• Idempotent Operations: All transactions and compensations must be safely retryable.
• Timeout and Retry Logic: Mechanisms to handle transient failures and avoid leaving the saga in an indeterminate state. This makes the pattern robust but adds significant complexity to error handling.

The Saga pattern is often contrasted with the Two-Phase Commit (2PC) protocol for distributed transactions.

• 2PC provides strong consistency (ACID) but uses synchronous coordination and locks resources for the transaction's duration, leading to poor availability and scalability under partitions (as per the CAP theorem).
• Sagas favor availability and scalability by avoiding long-lived locks. They accept eventual consistency and require developers to explicitly design compensating business logic, whereas 2PC relies on the transaction manager and resource managers for atomic rollback.

The Saga pattern is ideal for long-running business processes spanning multiple services, where strong, immediate consistency is not required. Common examples include:

• E-commerce order processing (check inventory, charge card, ship).
• Travel booking (reserve flight, hotel, car).
• Customer onboarding workflows. It is less suitable for operations requiring true atomicity (e.g., transferring funds between accounts in a banking core) or where designing semantically correct compensations is impossible (e.g., "send email" cannot be undone).

A semantic undo operation that logically reverses the effects of a previously committed local transaction. It is the fundamental building block of the Saga pattern.

Characteristics:

• Idempotent: Must be safely retryable.
• Business-Aware: Not a simple database rollback; it executes business logic (e.g., "cancel reservation," "issue refund").
• May not fully revert state: Due to external side effects, compensation often creates a new, acceptable state rather than a perfect rollback.

A consistency model where, in the absence of new updates, all replicas of a data item will eventually converge to the same value. This is the typical guarantee provided by the Saga pattern.

Contrast with Strong Consistency: Sagas favor availability and partition tolerance over immediate consistency. The system is allowed to be in an intermediate, inconsistent state during saga execution, with consistency restored once all steps (or compensations) complete.

The two primary coordination styles for implementing sagas.

Choreography:

• Decentralized control. Each local transaction publishes domain events. Subsequent services listen and trigger the next step.
• Pros: Loose coupling, simple.
• Cons: Complex debugging, cyclic dependencies possible.

Orchestration:

• Centralized control. A dedicated orchestrator (a state machine) invokes participants in sequence and manages compensation.
• Pros: Centralized logic, easier to monitor and debug.
• Cons: Orchestrator becomes a potential single point of failure.

The property of an operation whereby applying it multiple times produces the same result as applying it once. Critical for saga reliability.

Why it matters: Network timeouts and retries can cause a participant to receive duplicate execution commands. Both the local transaction and the compensating transaction must be idempotent. This is often implemented using unique idempotency keys passed with each request.

A reliability pattern used to ensure atomicity between publishing an event (e.g., for saga choreography) and committing the local database transaction.

Mechanism:

1. The service writes the event to an outbox table in the same local database transaction.
2. A separate relay process polls the outbox and publishes events to the message broker.

This prevents the system from being in a state where the local transaction commits but the event is lost, or vice-versa, which could break the saga's causal chain.