Saga Pattern

A Saga breaks a global transaction into T1, T2, T3... Tn steps, where each step is an atomic local transaction within its own service boundary. Each local transaction updates its database and publishes an event or message to trigger the next step. This avoids the performance bottleneck of distributed two-phase commit protocols. The pattern embraces eventual consistency, meaning intermediate states are visible to other services before the Saga completes.

If any step fails, the Saga executes compensating transactions in reverse order: C3, C2, C1. A compensating transaction is not a simple database rollback; it is a business-level operation that semantically undoes the effect of a completed step. For example, if T2 captured payment, C2 issues a refund. If T1 reserved inventory, C1 releases the hold. This requires developers to explicitly define undo logic for every forward step.

Two coordination strategies exist. Choreography distributes decision-making: each service listens for events and decides independently when to execute its local transaction, reducing coupling but obscuring the workflow. Orchestration centralizes control in a Saga orchestrator that commands each participant to execute and handles failure routing, providing explicit visibility into the process state at the cost of a single point of coordination.

Because Sagas lack a global isolation level, they suffer from anomalies not present in ACID transactions. - Lost Updates: One Saga overwrites another's write. - Dirty Reads: A Saga reads uncommitted data from another Saga that later compensates. - Fuzzy Reads: A Saga reads different versions of the same data across two steps. Mitigation strategies include semantic locks, commutative updates, and re-read verification.

Saga participants must be idempotent: processing the same message multiple times must produce the same result as processing it once. This is critical because network failures can cause duplicate message delivery. Implementations use idempotency keys stored alongside business data. Retry mechanisms with exponential backoff handle transient failures, while dead-letter queues capture messages that repeatedly fail for manual intervention.

A semantic undo operation that reverses the effects of a previously committed local transaction. Unlike a database rollback, a compensating transaction must account for intermediate state changes made by other concurrent processes.

• Semantic Undo: Reverses business effects, not just data bits
• Idempotent Design: Must be safely retryable without duplicate reversal
• Example: Issuing a refund and restocking inventory when a shipment is cancelled mid-process

Two fundamental coordination styles for saga execution. Choreography distributes decision-making where each service listens for events and triggers the next step. Orchestration centralizes logic in a coordinator that commands each participant.

• Choreography: Loose coupling, event-driven, harder to visualize end-to-end
• Orchestration: Centralized visibility, easier error handling, single point of control
• Hybrid Approach: Common in manufacturing where local agents handle cell-level logic but a plant-level orchestrator manages the production order

A consistency model where the system guarantees that if no new updates are made, all replicas will converge to the same state. In saga execution, intermediate states are visible to other processes before the saga completes.

• BASE Model: Basically Available, Soft state, Eventually consistent
• Isolation Gaps: Concurrent sagas may read uncommitted intermediate states
• Countermeasure: Semantic lock flags or reservation patterns on inventory

A unique identifier attached to each saga step to ensure that duplicate invocations produce the same result. Critical for at-least-once delivery semantics where network retries may cause a participant to receive the same command multiple times.

• De-duplication: Participants store processed keys to reject duplicates
• Idempotent Receiver: Design services to handle repeated identical requests safely
• Example: A production order ID used as the key prevents double-booking a CNC machine slot

A reliable messaging pattern that atomically writes a database update and an outgoing message within the same local transaction. Ensures exactly-once message delivery from each saga participant without distributed transactions.

• Change Data Capture: A separate process tails the outbox table and publishes messages
• At-Least-Once Delivery: Combined with idempotency on the consumer side
• Manufacturing Use: Guaranteeing that a quality inspection result is published even if the MES database write succeeds but the message broker call fails

A persistent, append-only record of every state transition and decision made during saga execution. Provides auditability and recovery capability if the coordinator crashes mid-process.

• Crash Recovery: Replay log to determine which steps completed and which remain
• Observability: Feeds into monitoring dashboards for stuck or long-running sagas
• Forensic Analysis: Traces root cause when a compensating transaction fails to execute