System designHard~20 minSystem Design Foundations Essentials / 5 of 15

Interview question

An order workflow reserves inventory, authorizes payment, and arranges shipment across separate services. How would you keep the business operation consistent when a later step fails?

Design a saga and compensating workflow

Designs a multi-service business workflow using local transactions, durable progress, idempotency, retries, and domain-specific compensation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would model the operation as a saga made of local transactions. For example, the order service creates a pending order, inventory reserves items, payment authorizes funds, and shipment accepts the request. Each successful step records its result and advances the workflow through a durable message. If a later step cannot complete, compensating actions release inventory or void the payment authorization. Compensation is a new business action, not a database rollback, so it must account for what has happened since the original step.

Full answer below

Practice focus

Saga design, local transactions, orchestration and choreography, compensation, idempotency, timeouts, durable state, observability, and manual recovery.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A business operation that crosses independently owned data stores cannot rely on one ordinary database transaction. The design needs a durable path to a valid final state even when only some steps succeed.
I would model the operation as a saga made of local transactions. For example, the order service creates a pending order, inventory reserves items, payment authorizes funds, and shipment accepts the request. Each successful step records its result and advances the workflow through a durable message. If a later step cannot complete, compensating actions release inventory or void the payment authorization. Compensation is a new business action, not a database rollback, so it must account for what has happened since the original step.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would choose orchestration when the sequence, timeouts, and recovery need one visible coordinator, and choreography when a small flow can progress through well-owned events without a central controller. Every handler needs idempotency because messages and compensation can be retried. An outbox or equivalent reliable publication prevents a committed local change from losing its next message. The saga stores correlation id, current state, completed steps, deadlines, attempts, and failure reason so the API can expose pending, completed, failed, or compensating status honestly.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would identify compensable steps, a point after which reversal is impossible or undesirable, and retryable steps that can drive the workflow forward. Irreversible side effects, such as a final external settlement, belong as late as the business allows. Timeouts need durable timers rather than one in-memory delay. I would monitor age by saga state, retry and compensation rates, stuck instances, and end-to-end completion time, with an operator path for cases that require human judgment. If all data still belongs in one service and one transaction, I would keep it there; a saga is justified by a real ownership boundary, not by the appeal of the pattern.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling a sequence of remote APIs inside one database transaction.
Treating compensation as a guaranteed reversal to the original state.
Publishing the next step without reliable linkage to the local commit.
Keeping saga progress only in memory.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Retries can charge, reserve, release, or notify more than once.
The workflow has no durable state or correlation identifier.
An irreversible action occurs before fallible validations and reservations.
Failed compensation has no alert, retry, or manual recovery path.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would you choose orchestration over choreography?
What if the compensation action also fails?
Which step is the point of no return in this workflow?

Continue the section

Next in System Design Foundations Essentials: Report Export Backend

Step 6 of 15

Design a backend for large report exports

Opening drill

System designHard~20 minSystem Design Foundations Essentials / 5 of 15

Interview question

An order workflow reserves inventory, authorizes payment, and arranges shipment across separate services. How would you keep the business operation consistent when a later step fails?

Design a saga and compensating workflow

Designs a multi-service business workflow using local transactions, durable progress, idempotency, retries, and domain-specific compensation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Saga design, local transactions, orchestration and choreography, compensation, idempotency, timeouts, durable state, observability, and manual recovery.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A business operation that crosses independently owned data stores cannot rely on one ordinary database transaction. The design needs a durable path to a valid final state even when only some steps succeed.
I would model the operation as a saga made of local transactions. For example, the order service creates a pending order, inventory reserves items, payment authorizes funds, and shipment accepts the request. Each successful step records its result and advances the workflow through a durable message. If a later step cannot complete, compensating actions release inventory or void the payment authorization. Compensation is a new business action, not a database rollback, so it must account for what has happened since the original step.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would choose orchestration when the sequence, timeouts, and recovery need one visible coordinator, and choreography when a small flow can progress through well-owned events without a central controller. Every handler needs idempotency because messages and compensation can be retried. An outbox or equivalent reliable publication prevents a committed local change from losing its next message. The saga stores correlation id, current state, completed steps, deadlines, attempts, and failure reason so the API can expose pending, completed, failed, or compensating status honestly.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would identify compensable steps, a point after which reversal is impossible or undesirable, and retryable steps that can drive the workflow forward. Irreversible side effects, such as a final external settlement, belong as late as the business allows. Timeouts need durable timers rather than one in-memory delay. I would monitor age by saga state, retry and compensation rates, stuck instances, and end-to-end completion time, with an operator path for cases that require human judgment. If all data still belongs in one service and one transaction, I would keep it there; a saga is justified by a real ownership boundary, not by the appeal of the pattern.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling a sequence of remote APIs inside one database transaction.
Treating compensation as a guaranteed reversal to the original state.
Publishing the next step without reliable linkage to the local commit.
Keeping saga progress only in memory.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Retries can charge, reserve, release, or notify more than once.
The workflow has no durable state or correlation identifier.
An irreversible action occurs before fallible validations and reservations.
Failed compensation has no alert, retry, or manual recovery path.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

An order workflow reserves inventory, authorizes payment, and arranges shipment across separate services. How would you keep the business operation consistent when a later step fails?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

An order workflow reserves inventory, authorizes payment, and arranges shipment across separate services. How would you keep the business operation consistent when a later step fails?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section