Back-of-the-envelope estimates

Before you pick a database, draw a load balancer or argue about Kafka, you need a rough sense of scale. Is it 50 requests per second or 500,000? Does the data fit in RAM on one machine, or is it petabytes? The answers decide the architecture, and you can get them in about two minutes of arithmetic on paper.

Back-of-the-envelope estimation turns a few assumptions about users, actions and object sizes into the numbers that drive a design: queries per second, storage growth, bandwidth and server count. You want the right order of magnitude, not precision. Being within a factor of two or three is enough to tell one server from a hundred, or one Postgres from a sharded cluster.

Reading order

Step	Concept	What it answers
1	Napkin constants	Which numbers should you know by heart?
2	Latency numbers	How far apart are memory, disk and the network?
3	The estimation chain	How do users become QPS, storage and servers?
4	A worked example for a Twitter-like app	What does a full estimate look like?
5	Read/write ratio and the one-machine check	Do you need a distributed system at all?
6	Estimation practice	Can you run three problems without help?

Steps 1 and 2 are constants you memorize. Steps 3 onward are the work itself.

Mistakes that cost the most

Mixing bits and bytes. Network links are quoted in bits per second. A "10 Gbps" link moves about 1.25 GB/s.
Forgetting the peak. Average QPS sets cost. Peak QPS sets capacity.
Forgetting replication and overhead. Raw data times 3 replicas times 2 for indexes is six times the number you first wrote down.
Too many significant figures. You are choosing between designs, not filing a budget. One significant figure is the right precision.
Hidden assumptions. "I'm assuming 20 timeline loads per user per day" invites a useful correction. A bare number invites suspicion.
Estimates that change nothing. Every number should move something: a cache, a shard key, a CDN, or a decision not to add a component.

Key takeaways

Memorize a few constants: 86,400 seconds is about 10^5, 1 million requests a day is about 12 per second, and the powers of two.
The chain runs from users to requests per day, average QPS, peak QPS, then storage, bandwidth and servers. State every multiplier.
The read/write ratio tells you where to invest. Always run the "is this one machine?" check.
An estimate is only useful if it ends with "so we need..."

In interviews and at work

In an interview, spend 2 to 5 minutes on estimation right after requirements (see the interview framework). Say your assumptions, compute average and peak QPS, storage and bandwidth, then state what each number implies. Interviewers care more about "so the read path needs a cache and the images need a CDN" than about whether you got 46,000 or 50,000.

At work, estimates show up in design docs, in capacity planning before launches, and in cost reviews.