Glossary · System coordination, integration and orchestration
Saga pattern
Also known as: Saga
German: Saga-Muster
In distributed software architecture, the saga pattern manages a business transaction that spans several services as a sequence of local transactions, each followed by the next; if a step fails, previously completed steps are undone by compensating transactions instead of a global rollback.
- System integration
In one sentence
The saga pattern runs a cross-service transaction as local steps and undoes completed steps with compensating actions if a later step fails.
Example
An order saga reserves material in the warehouse service, books capacity in the MES and creates a shipment; if capacity booking fails, the saga cancels the material reservation.
How it applies
- Engineering: Sagas can be orchestrated (a central coordinator calls each step) or choreographed (services react to each other's events). Each step needs a defined compensating action, which must itself be reliable and idempotent.
- Consistency: Sagas give eventual consistency: between steps, the system is temporarily inconsistent, and other processes may see intermediate states. Design for that.
- Physical processes: In manufacturing, some steps cannot be undone (material cut, product filled). Compensation then means a corrective action, such as scrapping or rework, which must be planned.
- Documentation: Document each saga with its steps, compensations and failure states, so support teams can resolve stuck transactions.
Saga pattern vs. two-phase commit
Two-phase commit locks all participants until everyone agrees, giving atomic commit but poor availability when a participant fails. A saga avoids long locks and works across independent services, at the cost of temporary inconsistency and explicit compensation logic.