Sagas

A saga splits one business transaction into a sequence of local transactions, one per service. Each step commits on its own. If a later step fails, earlier steps are undone by compensating actions.

A checkout saga

If payment fails, the saga releases the reservation and marks the order CANCELLED. The system passes through visible intermediate states, but it ends up consistent.

Orchestration or choreography

Durable workflow engines (Temporal, AWS Step Functions, Cadence) are orchestrators that persist every step, so a saga survives crashes and deploys and can wait days for a human approval.

Designing compensations

• Compensations are business actions, not undo: a refund, a cancellation email, a credit note. Some actions can't be undone at all (an email was sent), so order steps to put irreversible ones last.
• Every step and compensation must be idempotent and retryable, since messages and calls repeat.
• Compensations must eventually succeed. A refund that fails is retried, then escalated to a person; it can't simply give up.

Living without isolation

Other requests can see a saga's half-finished work. Common countermeasures:

• Semantic locks: pending statuses that other code respects.
• Commutative updates: increments and decrements that work in any order.
• Re-reading values before a step acts on them, such as checking the price again before charging.
• Pivot step: order the saga so everything before the point of no return is compensatable, and everything after it is retried until it succeeds.