The Saga Orchestration Concurrency
A single database transaction can commit or roll back atomically. Across many independent services there is no shared transaction, yet a business action like placing an order may span several of them: reserve stock, charge payment, schedule shipping. A saga coordinates such a multi step action as a sequence of local steps, each with a matching compensation that undoes it.
In the orchestration style a central coordinator drives the sequence. It calls step one, waits for success, then calls step two, and so on. If a later step fails, the orchestrator runs the compensations for the steps already completed, in reverse, to unwind the partial work.
- No global lock Each step commits locally, so there is no distributed transaction holding resources across services.
- Compensation Every forward step has an inverse, and failure triggers those inverses to restore consistency.
- Eventual consistency The system passes through intermediate states and converges, rather than being atomic at every instant.
Concurrency raises the stakes: steps may be retried, so they should be idempotent, and the orchestrator must track state durably so a crash mid saga can resume or compensate correctly.
Key idea
A saga splits a distributed action into local steps with compensations, and an orchestrator drives them forward or unwinds them, trading atomicity for eventual consistency.