Estimation Is Not Arithmetic: Find the Number That Decides the Design

A candidate is eleven minutes into a design and still multiplying. Peak-hour factor, replication multiplier, a per-record byte count carried to a suspicious level of detail, and at the end of it a storage figure that looks authoritative. The interviewer writes none of it down. Nothing in the remaining forty minutes will depend on that number, and by minute twelve both people in the room can feel it.

Back-of-envelope questions get treated as a maths test because they contain maths. They are not. The multiplication is the cheap part — you can do it, your interviewer can do it, and neither of you is interested in it. What is being assessed is whether you know which quantity the design hangs on. That is a judgement, and you make it before you calculate anything.

The ten-times test

Here is the only filter you need. Before you compute a number, ask: if I were wrong about this by a factor of ten, would a box on this board change?

Run it over the usual candidates for a photo-sharing service.

Total stored bytes: at 40 TB you use object storage; at 400 TB you use object storage. The number moved by ten and the design did not move at all. It changes a bill, not an architecture.

Writes per second: at 200 a single leader is comfortable and you can say so out loud; at 2,000 you are talking about partitioning, write-path batching and what your shard key is. Same tenfold move, entirely different board.

That asymmetry is why the load-bearing number is almost always a rate. Totals tell you which storage product to buy. Rates tell you how many things have to talk to each other, and it is topology, not capacity, that you are being asked to design.

Totals matter when they cross a line

This is not a rule that storage never counts. It counts when the total sits near a threshold that forces a structural change — the point where the working set stops fitting in memory, or the dataset stops fitting on one machine and you have to choose a partitioning key in front of the interviewer.

Which is the useful reframing: a number earns its place on the whiteboard only if you can name the threshold it is being compared against. "Forty terabytes" on its own is trivia. "Forty terabytes, and the hot subset is the last week — call it two per cent, so under a terabyte, which is a cache I can actually afford" is a decision.

If you cannot say what the number is being compared to, do not compute it.

Precision is a consequence, not a virtue

Once you know which quantity branches the design, the required precision falls out of the distance to the nearest threshold.

If your estimate lands an order of magnitude clear of the line, round savagely and move on. Call a day 100,000 seconds. Drop the peak multiplier if you are ten times below the limit anyway, and say that you are dropping it. Nobody is going to catch you out for approximating 86,400 when the conclusion is "one database, comfortably".

If your estimate lands near the line, that is the one moment in the hour when arithmetic is worth slowing down for — and the right move is to say so explicitly. "This comes out around the point where one leader stops coping, so the answer depends on whether the write rate is closer to 5,000 or 15,000. Which end should I assume?" You have just converted a shaky number into a question the interviewer can answer, and you have shown you know why the number mattered.

That sentence does more for you than three minutes of careful long multiplication ever will.

Do the estimate backwards

The conventional order is users, then requests, then storage, then bandwidth, and it produces four numbers of which roughly one is used. Try inverting it.

Start by naming the decision you are unsure about. Usually there are only two or three in any design: whether one database is enough, whether reads need a cache and replicas or just replicas, whether media needs a CDN at all, whether the write path can stay synchronous. Then compute only the figure that resolves each one, and say the conclusion in the same breath as the number.

Three numbers with three conclusions attached beats seven numbers and a shrug. It is also faster, which matters, because the estimate is not where the marks are — it is the thing that justifies where the marks are.

The tell

There is a giveaway phrase that separates the two approaches, and interviewers hear it immediately.

The arithmetic version ends with "so that's about 30 terabytes a year", and then a pause while the candidate waits to see if it was right.

The judgement version ends with "so that's about 30 terabytes a year, which means it doesn't fit on one machine within about eighteen months, so I want a shard key now even though I won't shard today". Same multiplication. The second one is a design decision with its evidence attached, and it survives the follow-up question — because the follow-up to an uninterpreted number is always "and so?"

Estimate to find the branch point. Everything else is decoration.