Saga pattern

Overview

A saga manages a business transaction that spans multiple services by breaking it into a sequence of local transactions, each in one service. If a step fails, the saga runs compensating transactions to semantically undo the steps that already succeeded, for example refunding a payment or releasing reserved stock. This provides eventual consistency without distributed locks or two-phase commit.

Sagas can be choreographed (each service reacts to events and emits the next) or orchestrated (a central orchestrator sends commands and tracks state). Orchestration is easier to understand and monitor for complex flows; workflow engines like Temporal, AWS Step Functions, and Camunda make orchestrated sagas durable and observable.

When to use it

• Multi-service business workflows: checkout, booking, account opening.
• Long-running processes that cannot hold locks.
• Microservices with a database per service.
• Workflows that need clear compensation logic.

Where it shows up in interviews

Where it is used in real software

Key terms

Local transaction

An ACID transaction within one service.

Compensating transaction

Semantic undo of a completed step.

Orchestrator

Central coordinator sending commands and tracking state.

Pivot transaction

Point after which the saga must complete (cannot compensate).

Semantic lock

Marking a record as pending to prevent conflicting changes.

How it works, step by step

1. 1
   Start the saga

   Create the order in PENDING state.

2. 2
   Execute steps

   Reserve inventory, charge payment, schedule delivery.

3. 3
   On failure, compensate in reverse

   Refund payment, release inventory, cancel order.

4. 4
   Make every step idempotent

   Retries and duplicate messages are expected.

5. 5
   Complete

   Mark the order CONFIRMED; persist saga state throughout.

Steps and compensations

Checkout saga

Order steps so the hardest-to-compensate actions (shipping, sending emails) come last, after the pivot.

Implementation

1import { proxyActivities } from "@temporalio/workflow";2import type * as activities from "./activities";3 4const { createOrder, cancelOrder, reserveStock, releaseStock, chargePayment, refundPayment, scheduleShipment, confirmOrder } =5  proxyActivities<typeof activities>({ startToCloseTimeout: "30 seconds", retry: { maximumAttempts: 5 } });6 7// Durable workflow: state survives crashes; each activity is idempotent8export async function checkoutSaga(input: { orderId: string; customerId: string; items: Item[]; totalCents: number }) {9  const compensations: (() => Promise<void>)[] = [];10  try {11    await createOrder(input);12    compensations.unshift(() => cancelOrder(input.orderId));13 14    const reservationId = await reserveStock(input.orderId, input.items);15    compensations.unshift(() => releaseStock(reservationId));16 17    const paymentId = await chargePayment(input.orderId, input.customerId, input.totalCents);18    compensations.unshift(() => refundPayment(paymentId));19 20    await scheduleShipment(input.orderId); // pivot21    await confirmOrder(input.orderId);22  } catch (err) {23    for (const undo of compensations) await undo(); // reverse order24    throw err;25  }26}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Non-idempotent steps or compensations.

  Fix: Every step will be retried; use idempotency keys.

• Compensations that can fail permanently.

  Fix: Design compensations to always eventually succeed; retry and alert.

• Irreversible actions early (sending an email).

  Fix: Place them after the pivot.

Interview questions

Practice problems