A marketplace charges the customer, pays the merchant, pays the courier and takes a fee. Design the transaction, and say what happens if the courier payment fails.
Show the full answer Hide the answer
What the interviewer is testing
Whether you order steps by compensability and know what to do when compensation is not appropriate.
The design
A saga with an orchestrator, because this is a business process with defined steps, a completion condition and an owner who will be asked about its status. Choreography would leave the process existing nowhere.
Order by reversibility. The general rule is that non-compensable actions come last — but here there is a more important structural point:
Separate the customer charge from the disbursements. The customer is charged (or the authorisation captured) at delivery. The payouts to merchant and courier are not synchronous with it; they are scheduled obligations, typically settled on a cycle.
That decoupling is the key design decision, and it changes the failure question entirely.
What happens if the courier payment fails
Nothing that affects the customer or the merchant. The delivery happened, the customer was charged correctly, the merchant is owed their share. The courier is owed money and the payout failed.
The correct handling is retry and escalate, not compensate. You do not reverse the customer's charge because a payout failed — that would be absurd, and it is what a naive "compensate everything" saga would do.
The obligation is recorded as a payable in a ledger. Payment attempts retry with backoff. A payout that keeps failing — invalid bank details, a compliance hold — escalates to a human, because there is no automated resolution for "this person's account details are wrong".
What a strong answer adds
Model the money as a ledger, not as a sequence of operations. Double-entry entries recording what is owed to whom, with payment execution as a separate concern that settles obligations. Then a failed payout is an unsettled obligation — a normal, queryable state — rather than an incident requiring compensation.
This is why financial systems are event-sourced or ledger-based: the record of obligations is the domain model, and payment execution is downstream of it.
And idempotency on every payout, keyed to the obligation, since retries are certain and a duplicate payout is money leaving the business.
Common weak answers
Compensating the customer charge when a downstream payout fails. Treating all four steps as a single atomic transaction.