A food-delivery marketplace takes a 12% commission on an average order of 400 rupees, and its contribution after paying delivery partners and payment fees is about 15 rupees per order. The platform team proposes a design that costs 3 rupees per order in infrastructure. Is that acceptable, and what does the answer change about the architecture?

The arithmetic first

Commission is 48 rupees per order. After partner and payment costs the platform keeps about 15. An infrastructure cost of 3 rupees per order is 20% of contribution, and that is before customer support, engineering salaries, marketing or discounts — the things that actually consume it.

For comparison, a subscription product with an 80% gross margin and a 2,000-rupee monthly price has roughly 1,600 rupees a month of room per customer. The same design decision is a rounding error in one business and a structural problem in the other, and the architecture is identical.

What is gained and what is paid

The design in question buys something real — call it lower latency, richer personalisation or a simpler operational model. What it pays is 20% of the only number that determines whether the business survives volume growth. A marketplace scales cost with orders, so an expensive per-order design gets worse with success, which is the opposite of how software is supposed to behave.

The useful concept is a unit cost ceiling: the infrastructure cost per transaction the business model can bear, set explicitly, before design. A defensible ceiling for a thin-margin marketplace is on the order of 2 to 5% of contribution, so here that is roughly 0.3 to 0.75 rupees per order, and the proposal is four to ten times over.

When the cost becomes visible

Not at launch, which is why this keeps happening. At 10,000 orders a day, 3 rupees is 30,000 rupees a day and nobody notices. At 2 million orders a day it is 6 million rupees a day, and by then the design is load-bearing: the cost is distributed across services, the caches are relied upon, and removing it is a quarter of work at the exact moment margin is under scrutiny. The bill arrives at the scale that was the goal.

What the ceiling changes about the design

• It makes precomputation preferable to per-request work. A recommendation computed once per user per hour and read from a cheap store costs a fraction of one computed per page view, and users cannot tell.
• It decides read paths. Serving from a materialised view is cents where a fan-out of five service calls with a database query each is not.
• It sets the honest limit on personalisation. Per-order machine-learning inference on a 15-rupee contribution is a business decision, not a platform decision, and it needs someone senior to say yes with the number in front of them.
• It makes cost per order a dashboard, alongside latency and error rate, owned by the platform team. A number nobody reports will not constrain anyone.

When this is the wrong answer

Early, when the priority is finding out whether anyone wants the product. A startup with 500 orders a day that optimises cost per order is optimising a number that will be irrelevant if the product does not work, and the engineering time is better spent on the thing that might. The ceiling starts to bind when a plausible growth plan multiplies today's volume by 100 and the arithmetic stops working. The rule: choose the expensive design deliberately with the multiplication done, and write down the volume at which you must revisit it.

Common weak answers

• "Infrastructure is cheap compared with engineers." True per engineer-hour and false per transaction. The comparison that matters is against contribution, not payroll.
• "We will optimise later." Sometimes correct, and only if you record what the optimisation is and what it will cost, because "later" is when the design is depended upon.
• "The cloud bill is the platform team's problem." Nothing about unit cost is decided by the platform team. It is decided by whoever chooses how much work happens per order.