Saga Pattern Vocabulary

The saga pattern exists because you cannot use a 2-phase commit (2PC) across microservices.

The problem sagas solve:
In a monolith, you can wrap a complex operation in a single database transaction — if any step fails, the whole thing rolls back atomically.

In microservices, each service owns its own database (Database Per Service pattern). You cannot create a single ACID transaction spanning multiple services. If an order creation involves the Order service, Payment service, and Inventory service — how do you ensure all succeed or all roll back?

The saga solution:
Break the distributed transaction into a sequence of local transactions, each in its own service. If a later step fails, execute compensating transactions in reverse order to undo the prior steps.

Example — Order creation saga:
① OrderService: Create order (local tx) → emit OrderCreated
② PaymentService: Charge card (local tx) → emit PaymentCharged
③ InventoryService: Reserve items (local tx) → emit ItemsReserved
④ ShippingService: Schedule delivery

If step ③ fails (out of stock):
← InventoryService: Emit ItemsReservationFailed
← PaymentService: Refund card (compensating transaction)
← OrderService: Cancel order (compensating transaction)

Key vocabulary:
• Saga — a sequence of local transactions that together accomplish a distributed operation
• Compensating transaction — an action that semantically undoes a prior completed step
• Distributed transaction — a transaction spanning multiple services or databases

Compensating transactions are business-level reversals, not technical rollbacks.

Why you can't just ROLLBACK:
The original local transaction has already committed and its effects are in place — money has been charged, emails have been sent, webhooks have fired. A SQL ROLLBACK is impossible. You must create a new forward action that achieves the opposite business effect.

Examples of compensating transactions:

Original action	Compensating transaction
Charge credit card	Refund credit card
Reserve hotel room	Release hotel room reservation
Deduct inventory	Restore inventory
Send confirmation email	Send cancellation email (can't unsend the first!)

The email example illustrates the key challenge: compensating transactions for observable external actions (email, SMS, bank transfers) may leave traces in the real world. This is why the result of a saga isn't necessarily identical to having never started — it's a semantic undo, not a perfect reversal.

Key vocabulary:
• Semantic rollback — undoing a business effect through a new forward operation
• Pivot transaction — the last irreversible step in a saga (after this, rollback is harder)
• Side effect — an external observable action that cannot be perfectly reversed

Choreography vs orchestration is one of the most important decisions when implementing sagas.

Choreography saga:
• Each service listens for events and decides what to do next independently
• No central coordinator — services are decoupled from each other through the event bus
• ✅ Highly decoupled, no single point of failure
• ❌ Business process logic is distributed — hard to understand the full flow from any single place
• ❌ Debugging is difficult — must trace events across many services to see what happened

Orchestration saga:
• A central saga orchestrator (or process manager) maintains the saga state and sends commands to each service
• The orchestrator knows the full flow and handles failures explicitly
• ✅ Business process visible in one place — easy to understand, monitor, and debug
• ✅ Explicit failure and compensation logic
• ❌ The orchestrator introduces coupling — services must implement the orchestrator's command interface
• ❌ The orchestrator can become a bottleneck

Which to choose?
• Simple 2–3 step processes with rare failures: choreography
• Complex multi-step workflows, many compensation paths, business-critical operations: orchestration

Key vocabulary:
• Saga orchestrator — the central service managing saga state and directing steps
• Process manager — an alternative name for the saga orchestrator pattern
• Choreography — decentralised coordination via reactive event handling

Saga state persistence is essential for reliable orchestration — crash recovery is a first-class concern.

How saga orchestrators maintain durable state:

The orchestrator saves its state machine checkpoint to a database after each step:
{ sagaId: "order-123", step: 3, status: "PaymentCharged", nextStep: "ReserveInventory", compensations: ["RefundPayment", "CancelOrder"] }

The Outbox Pattern is the key reliability mechanism:
① The orchestrator writes its state update AND the next command in the same local transaction to an "outbox" table
② A separate process reads the outbox and publishes the command to the message bus
③ If the orchestrator crashes, on restart it reads its saved state and reissues any unconfirmed commands

Why the Outbox Pattern matters:
Without it, the orchestrator might commit the state update but crash before publishing the next command — the saga would be stuck. The Outbox Pattern ensures atomicity between state persistence and message publishing.

Idempotency is also required (option A is partially correct): if a command is redelivered after a crash, the receiving service must safely ignore duplicate requests.

Key vocabulary:
• Saga state — the persisted checkpoint of which steps completed/failed
• Outbox Pattern — writing state and message to the same DB transaction; a background process relays the message
• Idempotency — safely handling a command that may be received more than once
• At-least-once delivery — the guarantee that a message will be delivered, but possibly more than once

Temporal coupling is a subtle but important reliability concern in long event chains.

The problem:
In a choreography saga with 7 steps, if Service #4 is slow (due to database load, traffic spike, or a bug), all steps #5–7 are blocked waiting for Service #4's completion event.

Effects of temporal coupling in a saga:
• Latency propagation — the whole saga runs at the speed of the slowest service
• Failure isolation is limited — a degraded service affects the entire saga's progress and eventually triggers timeouts
• Observability challenge — without distributed tracing, it's hard to identify which step is the bottleneck since events are anonymous across services

Mitigation strategies the team should discuss:
① Saga timeouts — each step has a maximum wait time; exceeded → start compensations
② Backpressure management — use consumer group lag monitoring to detect slow services
③ Saga state visibility — move to orchestration to get a single place that tracks timeouts
④ Bulkhead pattern — isolate the slow service so its slowness doesn't cascade

Key vocabulary:
• Temporal coupling — runtime dependency on the timing/availability of another component
• Consumer lag — how far behind a consumer group is on processing events
• Saga timeout — maximum allowed duration before a saga step triggers compensation
• Cascade failure — a failure in one component propagating through dependent components