The Inner Workings of the Saga Pattern

Not every step in a saga is equal

A saga is a sequence of local transactions across services, where each step has a compensating action that undoes it. The earlier lesson framed this as "step forward, or step back." But that framing hides the single most important structural fact about sagas: the ability to step back does not last the whole journey. At one specific point — the pivot — the saga stops being reversible and becomes committed to finishing.

Chris Richardson's classification makes this precise by splitting a saga's steps into three kinds: compensatable, the pivot, and retriable. Getting this structure right is what separates a saga that can always reach a consistent state from one that can get stuck.

The three kinds of transaction

Compensatable transactions

These come first. Each can be semantically undone by a compensating transaction (C1, C2, …). reserveStock is compensatable because releaseStock gives the units back. Compensation is not a database rollback — the local transaction has already committed — it is a new transaction that reverses the business effect.

The pivot transaction

The pivot is the go/no-go point. Richardson defines it as taking one of three distinct structural forms — these are alternatives that depend on how you have ordered the steps, not three names for the same thing:

• a transaction that is neither compensatable nor retriable — a genuinely irreversible commit, such as capturing a payment you have no automated way to refund, or dispatching a physical shipment; or
• the last compensatable transaction in the sequence, when everything after it is retriable; or
• the first retriable transaction, when that step is itself guaranteed to succeed and marks the point of no return.

What is common to all three forms is the guarantee that matters: if the pivot commits, the saga will run to completion.

Retriable transactions

These follow the pivot and are guaranteed to eventually succeed if retried. That guarantee is a design obligation, not luck: a retriable step may only fail for transient reasons — a timeout, a brief outage, a contended lock — that a retry will clear. A step that can fail for a business reason ("no courier slot," "insufficient funds," "address invalid") is not retriable and must never be placed after the pivot.

Two recovery directions, and no messy middle

Because a saga has no global rollback, it recovers in one of exactly two directions, and the pivot decides which:

• Backward recovery (abort). If a step fails before the pivot commits, the saga runs the compensating transactions for every completed compensatable step, in reverse order, and ends as if nothing happened.
• Forward recovery (commit). Once the pivot commits, the saga can only go forward. Each remaining retriable step is retried until it succeeds.

The crucial consequence: a committed pivot is never compensated. "Undo the pivot" is not a valid saga operation — if it were, the pivot would just be another compensatable step and would not be the pivot at all. This is exactly why there is no messy middle where the saga is stuck unable to go either way: every failure resolves to abort backward or drive forward, and the pivot is the clean line between the two.

A worked trace: order fulfillment

Stock starts at 8 units; a customer orders 3. Here is the saga, deliberately ordered so that every step that can fail for a business reason sits in the compensatable region, before the pivot:

Notice where reserveCourierSlot sits. Checking courier availability is a business decision that can legitimately fail, so it is a compensatable step placed before the pivot — never a retriable step after it.

Scenario A — failure before the pivot

T1 and T2 succeed, so stock is now 5. At T3, the Delivery Service reports no courier slot for the requested date — a genuine business failure. The saga has not reached the pivot, so it aborts with backward recovery, compensating the completed steps in reverse order:

1. C3 — nothing to release (T3 never secured a slot); skip.
2. C2 releaseStock — stock 5 → 8, returning the reserved units.
3. C1 rejectOrder — mark the order REJECTED and notify the customer.

The system is consistent again: stock is back to 8 and the order is cleanly rejected. Nothing was charged, because the pivot was never reached. This is the ordinary, correct use of compensation — it only ever touches the compensatable prefix.

Scenario B — failure after the pivot

This time T1–T3 succeed and T4 capturePayment commits: $60 is charged. The saga is now past the go/no-go point. At T6 confirmDelivery, the Delivery Service times out. This is a transient failure, so the saga does not compensate anything. Undoing the captured payment is not a valid saga operation, and the customer has paid. Instead it applies forward recovery: T6 is retried idempotently until the slot is confirmed, and the saga completes.

Contrast this with the broken design that puts a business-rejectable check after the pivot. If "is a courier available?" ran as a post-pivot step, a permanent "no slot" answer would leave the saga stuck: it cannot go forward (the step keeps failing) and it must not go back (the payment is committed and the pivot cannot be compensated). That stuck state is precisely the messy middle the pivot exists to prevent — and the fix is structural, not a workaround: move every step that can legitimately fail ahead of the pivot, as T3 does above.

What makes the guarantees hold

• The saga log. A durable record of each step and its outcome lets a crashed coordinator resume: replay to find the last committed step, then continue forward (if past the pivot) or compensate backward (if not).
• Idempotency. Retriable steps and compensations may run more than once after crashes, so each must be safe to repeat — releaseStock must not credit the 3 units twice.
• Deliberate ordering. Arrange steps so the riskier, business-rejectable work is compensatable and comes first, and the guaranteed-to-succeed work comes last. The pivot is a boundary you place on purpose, not one you discover after the fact.
• Eventual consistency. Between the first step and the final one the system is temporarily inconsistent; the saga's structure guarantees it always converges to either fully-done or fully-undone — never stuck in between.

Two coordination styles: choreography and orchestration

The same compensatable/pivot/retriable structure can be driven in two different ways. In choreography, each service completes its local step and emits an event; the next service listens and acts, with no central coordinator. It is simple early on and avoids a central bottleneck, but the flow is implicit in who-subscribes-to-whom, so recoverability logic and ordering constraints are scattered across services. In orchestration, a single saga coordinator issues commands to each service and records progress in its own saga log. It adds a component and a potential bottleneck, but the sequence, pivot placement, and recovery decisions live in one place and are explicit. Use choreography when the saga is short and the team wants minimal infrastructure; use orchestration when the flow is long, has strict ordering, or must be visible to operators and auditors.

The pivot is a choice you make, not a fact you discover

Which step is the pivot depends on what you can reverse, so it moves as your integrations change. If Payment exposed a reliable automated refund, capturePayment would become compensatable (its compensation is refundPayment) and the pivot would slide later — onto the first step that is genuinely irreversible, such as dispatching a physical shipment. The rule runs the other way too: an action with no undo — an irreversible "your order shipped" email blast you cannot recall — must never sit in the compensatable prefix, because a backward-recovery abort would then have to unsend something it cannot; place it at or after the pivot. This also gives operators a precise alarm: a log line showing a compensation attempted on a post-pivot step is a design bug, not a transient error, and should page a human rather than silently retry.

Takeaways

• A saga's steps fall into three kinds: compensatable (undoable), the pivot (go/no-go), and retriable (guaranteed to eventually succeed if retried).
• The pivot is one of Richardson's three distinct structural cases — neither-compensatable-nor-retriable, or the last compensatable step, or the first retriable step — chosen by how you order the saga, not three interchangeable descriptions.
• Failure before the pivot triggers backward recovery (compensate the completed steps in reverse, then abort). Once the pivot commits, only forward recovery applies (retry the retriable steps to completion). A committed pivot is never compensated.
• Put every step that can fail for a business reason before the pivot; only steps that can fail solely for transient reasons may follow it. This ordering is what removes the "stuck in the middle" state.
• The saga log plus idempotent steps are what let recovery survive crashes and let retries make safe forward progress toward eventual consistency.

Source

Adapted and corrected from the original lesson "The Inner Workings of the Saga Pattern" (System Design › Microservices Patterns). The compensatable / pivot / retriable classification and the two recovery-direction guarantees follow Chris Richardson, Microservices Patterns (Manning, 2018), Chapter 4, "Managing transactions with sagas," and microservices.io — Saga pattern.