Signals that it’s a multi-step workflow
- One action, several owners or companies
- Steps fail after others changed something
- Steps that wait: UPI, banks, humans
- “Where is order 81?”
Climb the ladder. The saga is rung 3, not the top.
Most of the interview is about what keeps it running through crashes, retries, code changes and peak load.
Choreograph the whole order?
Bad: Events between services
Nobody sees where order 81 is or owns its 10-minute timeout.
Good: Orchestrate the core flow
Choreograph only side effects like SMS and analytics.
Undo before the pivot, push forward after it
Reserving stock and taking payment can be compensated. The store accepting is the pivot; once packing starts, rider assignment and settlement are only retried.
The payment call timed out. Did it charge? Retry anyway?
The trick
Yes, with the same key, o81:charge, built from the order and step. Payments returns the stored result if the first call worked.
Durable execution: replay, don’t re-run
Each step’s result is appended to the order’s history. If worker A dies, worker B replays the code; finished steps return recorded results, so nobody is charged twice.
3.6M
orders in flight at the dinner peak
Little’s law: 2,000 orders a second × 30 minutes. At 10 transitions each, that’s 20,000 a second, beyond Step Functions’ default quotas and about $75,000 a month.
Say it like this
One database? One transaction. Otherwise a saga in a workflow engine: compensable steps before the pivot, retries after it, durable timers for waits, and an idempotency key per step.