Design an order saga: reserve inventory, take payment, dispatch shipment, send confirmation. What ordering problem do you see?

What the interviewer is testing

Whether you order saga steps by compensability, which is the most useful piece of saga design advice and the most frequently violated.

The problem

Dispatch is not compensable. Once a physical shipment leaves, there is no compensating action — only a returns process, which is a different business flow with real cost and a poor customer experience.

Sending a confirmation is also not compensable. You can send a correction; you cannot unsend.

So if dispatch succeeds and a later step fails, the saga cannot unwind cleanly.

The rule

Order steps so that non-compensable actions come last, after everything reversible has succeeded.

Revised order: reserve inventory (reversible — release the reservation), take payment (reversible — refund), then dispatch, then confirm.

That way any failure occurs while every completed step can still be undone.

The other design choices

Use reservations rather than commitments for scarce resources. Reserving inventory with a time-bounded hold means compensation is releasing a hold rather than reversing an allocation, and an abandoned saga expires naturally.

Authorise payment, capture on dispatch. Authorisation is a hold; capture is the irreversible step. Moving capture to the point of dispatch aligns the money with the goods and makes cancellation before dispatch clean.

Every step and every compensation must be idempotent, since both will be retried.

The saga's state must be durable, so an orchestrator crash mid-flow resumes rather than abandoning a half-completed transaction.

What must be built and is usually forgotten

Visibility into in-flight sagas and a means to intervene manually. Some will get stuck — a compensation that fails repeatedly, a step whose downstream is permanently unavailable — and without an operator interface the resolution is a developer writing database updates during an incident.

Failed compensations need escalation to a human, not infinite retry.

What a strong answer adds

Choosing orchestration over choreography here. This is a business process with defined steps, a completion condition, compensation requirements and an owner who will be asked about its status — all of which want a coordinator that can answer "where is order 4471".

Common weak answers

Accepting the original order and adding a returns compensation. Choreography for a flow that needs queryable state.