Saga pattern
A saga is a sequence of local transactions across multiple services that together accomplish a distributed business transaction. Because distributed ACID transactions are usually impractical, each step commits independently and a compensating action reverses it if a later step fails. Sagas come in two flavours: choreography (services emit events that trigger the next step) and orchestration (a central coordinator drives the flow).
The pattern dates to a 1987 paper by Hector Garcia-Molina and Kenneth Salem, originally about long-lived database transactions. The modern microservices revival recasts it as the answer to 'how do you book a flight, hotel, and car as one atomic-feeling operation when each is a separate service?' Choreography is simpler at small scale but becomes hard to reason about as the saga grows (no single place to see the flow); orchestration centralises that view but creates a coordinator bottleneck. Failure semantics matter most: every step needs an idempotent compensating action, and the compensations have to be designed for the failure modes the business actually tolerates (some can be eventually-consistent reversals; some need immediate rollback).
Related terms
- CQRS
Command Query Responsibility Segregation is an architectural pattern that splits a system's write path (commands that change state) from its read path (queries that return state) — typically with separate models, sometimes separate databases.
- Event sourcing
Event sourcing is a persistence pattern that stores every state change as an immutable event in an append-only log.
- Idempotency
An operation is idempotent if calling it multiple times has the same effect as calling it once.