Saga Pattern (Distributed Transactions)

A pattern for managing data consistency across multiple services without a distributed ACID transaction. A saga is a sequence of local transactions, each in a single service; each step has a corresponding compensating transaction that semantically undoes it. If any step fails, the saga executes the compensations for the already-completed steps in reverse, leaving the system in a consistent (rolled-back) state.

Microservices each own their database, so a single business operation spanning several of them can't use one BEGIN/COMMIT, since there's no shared transaction. Two-phase commit across services exists but is slow, locks resources, and couples availability to every participant. Sagas provide consistency without distributed locks: each service commits locally and independently, and failure is handled by compensating actions rather than a global rollback.

Two coordination styles. Choreography: each service listens for events and emits the next one ('SeatReserved' → Payment service charges → 'PaymentFailed' triggers seat release). No central coordinator; simple for short flows, tangled for long ones. Orchestration: a central orchestrator explicitly tells each service what to do and what to compensate, tracking saga state. On failure at step N, the orchestrator (or the event chain) invokes compensating transactions for steps N-1…1 in reverse. Compensations must be idempotent and semantic ('refund' rather than literal rollback, since the original commit is permanent).

• Achieves cross-service consistency without distributed locks or two-phase commit
• Each service commits locally and stays available independently, with no global lock holding everyone hostage
• Orchestration centralizes the flow logic, making complex multi-step processes explicit and observable

• No isolation: intermediate states are visible to others mid-saga (a seat looks booked before payment clears)
• Compensating transactions are extra code for every step and are themselves error-prone (what if the refund fails?)
• Only eventual consistency, and reasoning about all partial-failure orderings is genuinely hard

• Ticketmaster (Seat Booking) →

  Hold seat → charge card → issue ticket as a saga; a payment timeout triggers compensation that releases the held seat

• Airbnb (Marketplace) →

  Hold dates → authorize payment → confirm booking; if any step fails, compensations release the hold and void the authorization

• Payment Gateway →

  Multi-step charge flows (authorize, capture, notify) use compensating actions (void/refund) when a downstream step fails

• Sagas give you no isolation: other transactions can see intermediate state mid-flow (a seat shows held before payment confirms). You must design for these visible in-between states, not pretend they don't exist.
• Compensating transactions can themselves fail. Make them idempotent and retriable, and have a plan (alerting, manual intervention) for compensations that exhaust retries.
• Compensation is semantic, not a literal rollback, because the original local commit is permanent. 'Refund' undoes a charge in effect, but the charge event still happened and is in the history.
• Prefer orchestration for anything beyond a couple of steps. Choreography's implicit event chains become impossible to follow and debug as the flow grows; a central orchestrator keeps saga state observable.