Saga pattern
A business process across several services run as a chain of local transactions, with a compensating action to undo each step if a later one fails.
An order reserves stock, charges the card and books shipping, each in a different service. If shipping fails, the saga refunds the payment and releases the stock instead of rolling back. In choreography each service reacts to the others’ events; in orchestration one coordinator tells each service what to do. Other processes can see the in-between states, compensation is a business decision rather than an undo, and every step must be idempotent.
Related terms
- Two-phase commit (2PC): A protocol where a coordinator asks every database to prepare a change, then tells all of them to commit or all of them to roll back.
- Transactional outbox: Saving an event to an outbox table in the same database transaction as the change itself, then publishing it to the broker separately.
- Database per service: Each service owns its data and no other service reads its tables directly; the others go through its API or its events.
- Idempotency (idempotency key): An operation is idempotent if doing it twice has the same effect as doing it once. Retries become safe.
- Durable execution: Running a long process so its progress is saved after every step, letting it survive crashes and pause for hours or days, then resume.
