Why sagas exist
With database per service you cannot use one ACID transaction across services. A saga runs a business transaction as a sequence of local steps, each with a compensating action that undoes it if a later step fails.
Choreography
In choreography there is no central coordinator. Each service reacts to events and emits its own.
- It is decoupled and simple for short flows.
- But the overall logic is scattered and hard to follow.
Orchestration
In orchestration a central orchestrator tells each service what to do next and tracks progress.
- The flow lives in one place, easy to reason about and monitor.
- But the orchestrator can grow complex and is a focal point.
Choosing
Use choreography for a few loosely related steps; use orchestration when the flow is long, branchy, or needs clear visibility and rollback control.
Key idea
A saga splits a cross-service transaction into local steps with compensations; choreography decouples via events while orchestration centralizes the flow for clarity.