Saga Pattern

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 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.