Capstone: design on your own

Where will a twenty-minute grocery service break first?

The brief fits on one line: groceries in twenty minutes. Forty small warehouses across Pune that customers never visit, six thousand items in each, about 24,000 orders a day. You have a whiteboard, a marker and forty-five minutes, and the person across the table has read the same interview books you have.

The familiar boxes come first: an app, a service, a database. That drawing tells the interviewer nothing about this system, because every system can be drawn that way. What the person across the table wants to hear is what must never go wrong, what you would decide, and what each decision costs.

Until now every design began with a failure that had already happened: the double tap, the coupon script, the broker that died at lunch. Here you have to find the failures yourself, before they happen, and say which ones you will accept.

The kitchen designs still help. Think of each warehouse as a kitchen whose menu is whatever is on its shelves. A bag of groceries is an order with eight lines, and every line takes something scarce from one store. The money must be right. The riders are people, and there are only so many of them.

Try one number before drawing anything. If a tenth of the 24,000 orders land in the evening peak hour and each delivery keeps a rider busy for 25 minutes, how many riders are on the road at once? Keep your guess; the requirements will check it.

Then, before drawing a single box, ask for five minutes to write down the requirements.

Pause and predict Before you draw any boxes, name the one thing in this business that must never go wrong, and one thing you would allow to get worse at the evening peak.

What must never go wrong?

The system boundary is the place to start, and it is the one thing the brief already fixes.

A mental model

Seen this way, the data splits naturally by store: almost every frequent query is about one store. That is the partition key you will need when one city becomes ten (lesson 3.2).

When should stock be held?

Two goals compete. One is that customers never see “item no longer available” at checkout. The other is that stock is never locked by customers who do not buy.

Both serve a real goal: the first keeps customers who reach checkout from losing items, and the second keeps stock available for everyone else. With fast sellers and a 20-minute promise, stock locked by browsers costs more sales than the occasional last-unit disappointment. Lesson 6.3 measured the same trade-off for a flash sale.

What to remember

1. Start from what must never go wrong, then let an estimate decide what is scarce. Here it was riders and pickers, not servers.
2. Keep each decision local: one store, one database transaction, one idempotency key. Cross service boundaries with events from an outbox, not with locks.
3. Say where the system and reality can disagree (the shelf, the bank) and how you reconcile them.
4. Decide failures in advance: what customers see when the provider, a zone or the riders run out.
5. Every choice has a cost. Say what it is before the interviewer asks.

Write down what must never go wrong, then let one estimate tell you what is scarce before you draw a box.

In the real world

The reference design is deliberately small: one region, one database, a handful of services. Real quick-commerce companies add demand forecasting and replenishment, supplier integration, route planning, fraud checks and pricing, each a design of its own. None of that changes the method: requirements that can be measured, an estimate that decides, decisions that say what they cost, and failures chosen in advance.

If you could defend each step of this design to someone probing it, you have what this course set out to teach. The side quests go deeper on single ideas when you want them.

To practise that defence under interview conditions, take the mock interview: an unseen prompt, 45 minutes, an interviewer who cuts in, and a self-check against the rubric at the end.