Payments / Advanced / 6 min
Sagas: one order across many services
Order, stock, payment and courier in four services. When a step fails, compensating actions undo the rest, newest first.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A saga splits one business action into local steps in different services, each with a compensating undo used if a later step fails.
- Why it matters
- Microservices each own a database, so there is no single transaction across them, and two-phase commit blocks and scales poorly.
- The trade-off
- The system is briefly inconsistent while a saga runs, undos are not always perfect (an email cannot be unsent), and they must be idempotent.
- Say it in an interview
- "An orchestrated saga: order service drives reserve stock, charge, book courier; on failure it runs refund, release, cancel, with each step idempotent and retried."
Check yourself
Why use a saga instead of one database transaction for an order?
Answer: The steps live in different services and databases, so no single transaction can cover them. Each microservice owns its data; a saga coordinates local transactions instead of a distributed lock across all of them.
Payment succeeded but booking the courier failed. What does the saga do?
Answer: Runs compensating actions: refund the card, release the stock, cancel the order. Each successful step has an undo, run in reverse order, so the system ends consistent.
What must compensating actions be?
Answer: Safe to retry (idempotent), because they may run more than once after failures. An undo can be retried after a crash, so refunding twice must not happen; use idempotency keys.