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.

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.