05Design patternsMulti-step processes and sagas
05 · Reusable pattern
Multi-step processes and sagas
Coordinate long business workflows with persisted state, compensations, and visible partial failure.Lesson spine
What you need to understand.
A saga persists the progress of a multi-service workflow and uses forward recovery or compensation when one local transaction fails.
Local transactions
Each service commits only its own state and emits an outcome the saga can observe.
Orchestration
A workflow owner stores the current step and commands the next action, making status, timeout, and repair visible.
Choreography
Services react to events without a central coordinator, reducing central coupling but making the full process harder to understand.
Compensation
Define a business action that semantically reverses an eligible step; not every external effect can be undone.
Retries and idempotency
Every step and compensation needs a stable identity, bounded retry, and terminal failure policy.
Operator experience
Expose stuck age, completed steps, next retry, compensation status, and a safe manual action.
Before the boxes
Frame the decision.
What must work
Coordinate long business workflows with persisted state, compensations, and visible partial failure.
What changes the design
Workflow duration · retries · compensation success · stuck age · state counts
What owns the truth
Identify the component that commits authoritative state, then separate synchronous confirmation from derived work.
What stays simple
Do not add global coordination, multi-region writes, or a specialized store until a requirement earns the complexity.
Architecture map
Trace ownership, not just traffic.
Follow the decision from left to right. Every arrow should have a reason.
Starts process
Owns workflow state
Commits local transaction
Advances the saga
Reverses eligible effects
Surfaces stuck cases
Walk one representative request across every arrow. Say whether the handoff is synchronous or asynchronous, what identity makes a retry safe, and which step changes authoritative state.
- 01
Initiator — Starts process Define the output contract before moving to the next owner.
- 02
Saga store — Owns workflow state Define the output contract before moving to the next owner.
- 03
Step service — Commits local transaction Define the output contract before moving to the next owner.
- 04
Bus — Advances the saga Define the output contract before moving to the next owner.
- 05
Compensator — Reverses eligible effects Define the output contract before moving to the next owner.
- 06
Operator view — Surfaces stuck cases Confirm the result and emit the evidence needed to reconcile it.
Decision table
Make the trade-offs explicit.
| Decision | Defensible position | Cost to acknowledge |
|---|---|---|
| Primary mechanism | Orchestration centralizes state; choreography reduces central coupling but hides the whole workflow. | The stronger guarantee usually adds coordination, latency, state, or operational work. |
| Sync vs. async | Keep only correctness-critical confirmation synchronous. Move derived views, notifications, analytics, and cleanup behind a durable boundary. | Async work needs idempotency, lag monitoring, replay, and a product definition for partial completion. |
| Simple vs. scaled | Begin with one logical owner and a clear API. Partition or replicate only the resource proven to be the first bottleneck. | Migration requires stable identities, versioned contracts, backfill, and a rollback path. |
Failure review
Design the recovery path.
Topic-specific risk
Compensation may fail or be impossible after an external side effect.
ResponsePersist enough identity and state to distinguish retry, resume, compensation, and operator repair.
Dependency timeout
A timeout is ambiguous: the remote side may have failed, succeeded, or still be running.
ResponseUse deadlines, bounded backoff with jitter, idempotency keys, and a status or reconciliation path.
Overload or skew
Average capacity can look healthy while a tenant, key, partition, region, or expensive request saturates one owner.
ResponseExpose queue depth and hot-key share, apply backpressure, isolate tenants, and degrade optional work before correctness.
Evidence + level bar
Prove the design can be operated.
Health of the promise
Measure user-visible latency or freshness, correctness drift, saturation, retry volume, and time to recover. Alert on the failed promise—not only CPU.
Complete and clear
Finish the happy path, identify the state owner, choose reasonable building blocks, and explain one scale mechanism.
Trade-offs and failure
Separate read and write paths, define consistency, explain partitioning, and make duplicate or partial failure safe.
Evolution and operations
Discuss multi-region boundaries, migration, tenant isolation, capacity, observability, and how the architecture changes over time.
Interview language
Open the deep dive with a claim.
“For Multi-step processes and sagas, the decision I want to make explicit is this: Orchestration centralizes state; choreography reduces central coupling but hides the whole workflow. I’ll trace the state-changing path first, show where the result becomes durable, then test the design against the highest-risk failure and our target scale.”
08 · Retrieval check
Can you defend it without the page?
- For Multi-step processes and sagas, where is the correctness boundary and which failure would you test first?
- Which component owns committed truth, and what event or response proves the commit?
- Where is the first scaling or coordination bottleneck under the stated envelope?
- What happens after an ambiguous timeout or duplicate operation?
- Which complexity would you remove at one hundredth of the scale?