Saga Pattern

A saga breaks a global transaction into T1, T2, ..., Tn steps, where each step is an ACID local transaction within its own bounded context. Each local transaction updates its database and publishes an event or message to trigger the next step. This avoids the performance bottlenecks of two-phase commit (2PC) protocols, which lock resources across services. In a logistics context, T1 might reserve warehouse inventory, T2 schedules a carrier pickup, and T3 charges the customer—each operating on its own service database.

Every forward transaction Ti has a corresponding compensating transaction Ci that semantically undoes its effects if the saga fails. Unlike a database rollback, compensation is application-level logic: if a payment is captured, the compensating action issues a refund; if a shipment label was generated, the compensation voids it. Compensating transactions must be idempotent to handle retry scenarios safely. This is the core mechanism that maintains eventual consistency across the distributed system.

Sagas are implemented in two architectural styles:

• Choreography: Services react to events directly. Each service listens for the completion event of the previous step and executes its local transaction. This is decoupled but obscures the workflow.
• Orchestration: A central saga orchestrator explicitly commands each service and handles failure responses. This centralizes the workflow logic, making the process explicit and monitorable, which is preferred for complex logistics processes with many branching failure modes.

The saga pattern defines two recovery strategies:

• Backward Recovery: When a step fails, the orchestrator executes the compensating transactions for all previously completed steps in reverse chronological order. This restores the system to its initial state.
• Forward Recovery: For failures that are transient, the saga can retry the failed step or continue through an alternative path, skipping non-critical steps. This is common in logistics where a carrier unavailability might trigger a re-route rather than a full cancellation.

Because sagas do not hold locks across services, they suffer from isolation anomalies not present in ACID transactions:

• Lost Updates: One saga overwrites another's changes.
• Dirty Reads: A saga reads uncommitted data from another incomplete saga.
• Non-repeatable Reads: A saga reads the same data twice and gets different values. Mitigation strategies include semantic locks (application-level flags), commutative updates, and version vectors to detect conflicts before committing.

Saga participants must handle at-least-once delivery of commands due to network retries. Every transaction and compensation must be idempotent: executing it multiple times produces the same result as executing it once. This is achieved through idempotency keys—unique identifiers attached to each command that the receiver stores and deduplicates. In logistics, a shipment_id serves as a natural idempotency key, preventing duplicate label generation.

The semantic inverse of a forward operation, designed to undo a committed local transaction without relying on traditional database rollbacks. In a travel booking saga, if a flight is successfully booked but a hotel reservation fails, the compensating transaction cancels the flight. Unlike ACID rollbacks, this is a distinct business operation that must be idempotent and handle partial failure states. The key design challenge is that compensation cannot simply restore a previous state if intermediate modifications have occurred—it must apply business logic to semantically negate the effect.

Two competing coordination models for saga execution:

• Choreography: Each service publishes events after completing its local transaction, triggering the next participant. This is decentralized and reduces coupling but obscures the end-to-end workflow.
• Orchestration: A central coordinator explicitly invokes each participant in sequence and manages compensation logic. This provides visibility and control but introduces a single point of coordination. The choice hinges on complexity tolerance and observability requirements.

A consistency model where the system guarantees that if no new updates are made, all replicas will eventually converge to the same state. Sagas embrace this model by allowing intermediate states to be visible across services. For example, an order may appear as 'confirmed' in one service while payment is still 'processing' in another. This is formalized in the CAP theorem trade-off: sagas prioritize availability and partition tolerance over strong consistency, making them suitable for high-throughput, globally distributed systems.

A critical companion to sagas that ensures atomicity between database writes and message publication. Instead of directly publishing an event after a local transaction, the service writes the event to an outbox table within the same database transaction. A separate process then reliably publishes these events to a message broker. This eliminates the dual-write problem where a database commit succeeds but the message publication fails, which would break saga consistency guarantees.

A unique identifier attached to saga participant requests to ensure that retried operations do not produce duplicate side effects. When a coordinator retries a failed step, the participant uses the idempotency key to recognize the duplicate and return the original result rather than re-executing. This is essential because sagas rely on at-least-once delivery semantics from message brokers. Common implementations use a unique constraint on a database column storing processed keys with their responses.

The contrasting distributed transaction protocol that sagas were designed to replace in long-running scenarios. 2PC uses a coordinator to execute a prepare phase (all participants agree to commit) followed by a commit phase. While 2PC guarantees strong consistency, it holds locks for the entire duration, making it unsuitable for transactions spanning minutes or hours. Sagas trade this locking overhead for eventual consistency and explicit compensation, avoiding resource contention in microservice architectures.