An interviewer sets the exercise on a food-delivery platform of Zomato's kind - assume a flat delivery fee of $2.00 and a 70% gross-margin target on that fee. Work backwards to the infrastructure budget per order and then tell me what you would do with the number.

What the interviewer is testing

Whether a business constraint can become an engineering budget in your hands. Most candidates can compute cost per order after the fact. The senior move is deriving the ceiling before the architecture exists and then allocating it across the request path, so that design reviews have a number to check against.

The clarifying questions that change the answer

• Does the fee include the courier payout? If it does, most of the 30% cost allowance is a third-party payment and the technical budget is a small remainder. If it does not, the whole allowance is yours.
• What else is per-order and paid outside? Payment processing, geocoding and routing calls, messaging, fraud scoring. These are billed per event and infrastructure work does not reduce them.
• Which unit? Cost per order flatters a product where orders are falling as a share of sessions. Ask for both, and for the ratio between them.
• Average or peak? Two hours a day carry most of the volume. A budget derived from average cost is wrong by the ratio of peak to average, because idle capacity is paid for 24 hours.

A strong answer's arc

Take the fee at \(2.00 and the margin target at 70%. That leaves **\)0.60 per order for everything in cost of goods sold. Say pass-through takes $0.45 of it - payout share, payment fees, per-call third-party APIs. The entire technical budget is then about $0.15 an order**, and that has to cover compute, storage, telemetry, support tooling and the share of platform spend allocated to this flow.

Now allocate it, because a single number cannot be designed against. A workable split is roughly $0.05 to the order and dispatch path, $0.04 to search and browse, $0.03 to telemetry and data, $0.03 to everything shared. Publish it like a latency budget. A feature that adds a billable third-party call per order is spending from the same envelope as a new database, and only a published budget makes that visible at review time rather than at the quarterly cost review.

Common weak answers

• "Reduce cloud spend by 20%." Not derived from anything. It cannot tell you whether a feature is affordable.
• Quoting cost per request with no business unit attached. Twelve requests per order means a per-request figure is twelve times less informative than it looks.
• Ignoring peak. A budget built on the daily average is met on paper and broken every evening.

What a strong answer adds

The admission that the binding constraint is usually not infrastructure. When pass-through takes three quarters of the allowance, the highest-value engineering work is removing billable third-party calls per order - caching geocodes, batching routing requests, deduplicating notifications - rather than shaving compute. Saying that in an interview shows you can find where the ceiling actually binds, and the cost reviews that follow stop being about instance sizes.