Sagas: multi-step workflows across services with compensation instead of rollback

What it is

The microservices.io pattern page (cited) defines a saga as a sequence of local transactions: each updates one service's database and publishes a message or event that triggers the next local transaction. If a local transaction fails because it violates a business rule, the saga executes compensating transactions that undo the changes made by the preceding steps. Coordination is either choreography (each service reacts to events) or orchestration (an orchestrator tells participants what to do). The page lists the drawbacks: no automatic rollback, since compensations are hand-written, and no isolation, so concurrent sagas can read each other's intermediate state.

The Azure Architecture Center (cited) adds a useful vocabulary: compensable transactions can be undone; a pivot transaction is the point of no return, after which the saga must run forward to completion; retryable transactions follow the pivot and are idempotent so that the saga can always finish.

Why it matters

Once data lives in several services, "create order, reserve stock, charge card" cannot be one database transaction. Without an explicit saga the failure paths are implicit: a charge with no order, stock reserved forever.

How to apply

• Write the happy path as a list of steps and, next to each compensable step, its compensation. If a step has no meaningful compensation (an email sent, a payment captured), it is the pivot or must come after it.
• Order steps so that the ones most likely to fail on business rules come first and the irreversible step comes last.
• Make every step and every compensation idempotent and keyed by the saga id, because messages are delivered at least once.
• Persist saga state (which step succeeded) so that a restarted orchestrator resumes rather than restarts; publish the triggering events through an outbox.
• Handle the isolation gap deliberately: mark records as pending until the saga completes, and have readers treat pending state accordingly.
• Set a timeout per step and define what happens on expiry (compensate or escalate to a human).

Pitfalls

A compensation is a new business action, not a rollback: refunding is not un-charging, and it can itself fail and need retry. The Azure page describes choreography as suited to simple workflows with few services and notes that the flow becomes confusing as steps are added; an orchestrator with a visible state machine is easier to operate for longer sagas. Sagas do not remove the need for the last step to be idempotent under retries.