Scoping the Problemlesson 4 of 4 · 3 min read

Back of the Envelope

Why the estimate exists

The estimate is not arithmetic for its own sake. It tells you which designs are impossible, and it takes under three minutes.

The order matters. Users to requests per second: daily actives times actions each, divided by 86,400 seconds, then multiplied by two or three for peak because traffic is never flat. Requests to storage: writes per second times bytes per write times seconds in a year, which is about 31.5 million. Storage to bandwidth: requests per second times payload size, counting in and out separately when they differ.

Rounding hard is the point. Treat 86,400 as 100,000. A day is ten to the fifth seconds and a year is three times ten to the seventh. You want an order of magnitude, because the decision in front of you is whether something fits on one machine or needs a fleet, and being 40 percent out never changes that answer. Reach for precision here and you are optimising the wrong thing while the clock runs.

Each number should kill an option

Let each number rule something out. A terabyte in total means one database instance is fine and sharding would be premature. A petabyte means object storage and a metadata layer. Two thousand queries per second is comfortable for one database and two million is not. Five megabytes per second of traffic leaving your servers is nothing, and five gigabytes per second is a content delivery network conversation and a bandwidth bill worth mentioning.

What each number rules out is worth saying as you get it, because that is the part being scored. “200 million businesses at 5 KB is a terabyte, so storage is not the constraint here, the rate of requests is” shows the judgement. The same arithmetic with no conclusion attached is just arithmetic, and it is a common way to spend four minutes and earn nothing.

A few figures are worth having ready so you are not deriving them live. One machine handles roughly 10,000 to 50,000 simple requests per second. A single relational database node sustains something like 5,000 to 10,000 writes per second. Memory is about a thousand times faster than a solid state disk, and a round trip inside one data centre is around 500 microseconds.

the shape of it

step 1 of 3

Each figure eliminates a class of design, which is the only reason to compute it.

Worked example

Design a photo sharing service. The candidate does it in three steps out loud. Users to requests per second: 50M daily actives, 2 uploads a day, so 100M uploads over roughly 10^5 seconds, about 1,000 writes per second, call it 3,000 at peak. Reads at 100 to 1 gives 100,000 reads per second, which is immediately the interesting number and rules out serving images from application servers.

Storage: 100M uploads a day at 2 MB each is 200 TB a day, which is 73 petabytes a year. They stop and say what that rules out: no database stores this, so photos go to object storage and the database holds metadata only, and at that volume the retention policy is a real product question rather than an afterthought.

Bandwidth: 100,000 reads per second times 2 MB is 200 GB per second of egress, which nobody serves from origin. That is the CDN, and now it is in the design because the arithmetic put it there rather than because photo apps usually have one. Three multiplications, and the shape of the entire system is already decided.

Scoping the Problem: wrapping up

In the real world

01Every design doc at a large company opens with context and goals before architecture, and reviewers push back hardest when a proposal skips straight to components. The interview format is compressed practice for that review.
02Google's SRE practice formalises the availability half of this as SLOs, set deliberately below what users would ideally want, so the error budget becomes a spending decision rather than an aspiration.
03Amazon's working-backwards process starts from the press release and FAQ rather than the system, which is the same instinct: agree what is being built and for whom before anyone designs it.
04The read-write ratio decides architecture in production the same way it does in interviews. Yelp and similar products lean on precomputed, cached candidate sets precisely because their reads outnumber writes by orders of magnitude.
05Estimation appears in capacity planning every quarter: DAU to QPS to instance count is how teams argue for hardware, so the interview skill is the job skill with a shorter deadline.

Questions people ask

How long should I actually spend on this?

About ten minutes of a 45 minute interview. Long enough to fix the feature set, the scale, the latency target and the read-write ratio, short enough to leave the bulk of the hour for design. If you are at fifteen minutes with no boxes drawn, state your assumptions and move.

The interviewer keeps saying "you decide". What do I do?

Decide, out loud, with a number. "I will assume 10 million daily actives, read-heavy at roughly 100 to 1" is the expected answer. The deflection is the test: they want to see whether you can commit to an assumption and design against it, not whether you can keep asking questions.

Is it a problem if my estimate is wrong?

Only if the order of magnitude is wrong. Being out by 40 percent changes nothing, because the decision the number drives is whether something fits on one machine or needs a fleet. State your assumptions as you go so the interviewer can correct an input rather than doubting the whole approach.

Quick review

The prompt is deliberately vague:: "design Twitter" has no scope, and the interviewer is watching whether you invent one or start drawing boxes
Functional requirements:: name the two or three user journeys you will support and say out loud what you are cutting. A design that does everything demonstrates nothing; Non-functional requirements are the ones that shape architecture: scale, latency target, consistency needs, availability. Ask for them, and if the interviewer shrugs, propose numbers yourself
Turn adjectives into numbers:: "fast" becomes p99 under 200 ms, "lots of users" becomes 10M DAU, "always available" becomes three nines and a defined failure mode
Read-write ratio first:: it decides caching, denormalisation and replication before any component is chosen. A 100:1 read-heavy system is a different design from a write-heavy one
Back of the envelope in this order:: DAU to QPS, QPS to storage per year, storage to bandwidth. Round hard, because you want an order of magnitude, not accuracy
State the scope back before moving on:: "so we are building X for Y users at Z reads per second, ignoring A and B". That sentence is the contract for the rest of the hour; Write the constraints somewhere visible and refer back to them. Every later trade-off should be justified against a number you agreed at the start

the trade-off

Time spent scoping is time not spent designing, and an interviewer who wanted depth can read a long requirements phase as stalling. Timebox it, keep it conversational rather than a checklist recital, and move on as soon as you have the handful of numbers that constrain the architecture. Scoping earns its place by making later decisions defensible, not by being thorough for its own sake.

in the room

The opening of every system design interview, and any real design doc. Ten minutes of a 45 minute interview is the standard split.

the short version

Three multiplications that rule out most of the designs before you draw one.