Saga Pattern

A saga breaks a global business process into a chain of independent local ACID transactions. Each step updates data within a single service boundary and publishes an event or message to trigger the next step. This avoids the performance bottlenecks of two-phase commit (2PC) protocols by never holding locks across service boundaries. The orchestrator or choreographer ensures the sequence executes in the correct order, with each local transaction committing immediately before the next begins.

Every forward operation in a saga must have a corresponding semantically undoing action. Unlike a database rollback, a compensating transaction is a business-level operation that reverses the visible effects of a committed step—such as canceling an order or releasing reserved inventory. This is essential because once a local transaction commits, its data is visible to other operations and cannot be rolled back atomically. The saga executes these compensations in reverse chronological order if a failure occurs mid-sequence.

Two coordination styles exist for sagas:

• Orchestration: A central coordinator object tells each participant what to do and handles failure logic. This provides a clear, single point of control and is easier to reason about.
• Choreography: Each service listens for events and decides independently when to act, publishing its own events upon completion. This reduces coupling but distributes the saga's state machine across services, making the overall flow harder to trace. The choice depends on the complexity of the workflow and the team's tolerance for distributed logic.

Sagas embrace eventual consistency rather than strong consistency. Between the commit of one local transaction and the next, the overall system is in a transient, inconsistent state. This is acceptable for long-running business processes where immediate global consistency is not required. The system guarantees that, given no new failures and successful completion or compensation of all steps, the data will converge to a consistent state. Monitoring this intermediate state is a key operational concern.

Robust sagas require idempotent operations at every step. Network failures can cause duplicate messages, so each participant must safely handle receiving the same command multiple times without executing duplicate business logic. The saga coordinator must also implement retry logic with exponential backoff for transient failures and a defined escalation path for permanent failures. If a step cannot be completed after all retries, the coordinator initiates the compensating transaction chain to semantically undo all previously successful steps.

Because sagas do not hold locks across service boundaries, they are susceptible to isolation anomalies not present in ACID transactions. A common example is the lost update problem, where another transaction reads and modifies data between a saga's local commit and a subsequent compensating action. Mitigation strategies include semantic locks (application-level flags), commutative updates (operations that can be applied in any order), or version vectors to detect conflicting intermediate writes before applying a compensation.

The semantic undo operation that reverses a committed local transaction. Unlike a simple database rollback, a compensating transaction must account for side effects and concurrent updates that occurred after the original step committed.

• Design: Must be idempotent to handle retry failures safely
• Example: A cancelShipment() operation that creates a return label, rather than simply deleting a row
• Contrast: Distinct from a rollback, which reverses uncommitted changes in a single database

Two primary coordination models for executing a saga.

• Choreography: Decentralized; each service publishes domain events that trigger the next local transaction in the chain. Highly coupled to event schemas.
• Orchestration: Centralized; a dedicated Saga Execution Coordinator sends commands and listens for replies. Simplifies monitoring and error handling at the cost of a single point of control.
• Trade-off: Choreography reduces coupling but obscures the business process flow.

A consistency model where the system guarantees that if no new updates are made, all replicas will eventually converge to the same state. The Saga Pattern embraces this model.

• Mechanism: Relies on asynchronous message passing and retries
• Relevance: During saga execution, the overall system state is temporarily inconsistent until all steps complete or compensate
• Contrast: Opposed to strong consistency, which requires all nodes to agree on a value before a write is confirmed

The property of an operation where applying it multiple times has the same effect as applying it once. Critical for saga reliability.

• Implementation: Use a unique idempotency key per transaction step
• Purpose: Prevents duplicate execution when a coordinator retries a command due to a network timeout
• Scope: Both forward transactions and compensating transactions must be idempotent to handle at-least-once delivery semantics

A reliable messaging pattern often used to implement saga coordination. It ensures atomicity between a database write and a message publication.

• Process: The service writes the event to an outbox table within the same local transaction as the business data
• Relay: A separate process polls the outbox and publishes the message to a message broker
• Benefit: Eliminates the dual-write problem, guaranteeing that a message is always published if the state changes

A mechanism to restrict access to a shared resource across multiple processes. Used in sagas to prevent conflicting operations on a shared entity.

• Use Case: Preventing two concurrent sagas from modifying the same order
• Implementation: Often built with a strongly consistent data store like Redis or etcd
• Risk: Introduces a single point of contention and requires careful lease management to avoid deadlocks if a lock holder crashes