Designing from the numbers, not the diagram

Asked to design a system, most people start drawing boxes. A load balancer, three services, a queue, a cache, two databases.

The interviewer's next question is always the same: why? And the honest answer is usually that those are the boxes in every diagram they have seen.

Start with what it has to do

Before any box, get three things:

1. 1Who uses it and to do what. Two or three sentences.
2. 2How much. Users, requests per second, data volume, growth.
3. 3What must not happen. Lost orders? Stale reads? Downtime at 9am?

The third is what turns a diagram into a design, because it is what the trade-offs are made against.

Do the arithmetic out loud

One million users, each doing ten actions a day, is ten million actions a day. Divide by 86,400 and that is about 120 a second on average, and perhaps 600 at peak.

That number changes everything. 600 a second is one modest server and a database. It is not a queue, a cache and three services, and saying so is a better answer than drawing them.

Then name the trade

Every decision costs something, and the sentence an interviewer is waiting for has this shape:

I am adding a cache because reads are 100 times writes. The cost is that a reader can see data up to a minute old, which is acceptable here because it is a product page and not a bank balance.

Choice, reason, cost, why the cost is acceptable. A design without that last clause is a diagram.