Back-of-the-envelope estimation

Why estimate at all

A design for 10 requests a second and one for 100,000 look nothing alike. The first fits on one machine; the second needs caches, many servers and probably split-up data. A back-of-the-envelope estimate is a two-minute calculation that tells you which world you're in.

The rule for interviews and real work alike: only estimate what changes a decision. If the answer to "how much storage?" is "a few hundred gigabytes", that settles it (one disk) and you move on. Long tables of numbers that nobody uses are wasted time.

The method

Five steps, each one a multiplication or division:

Round hard at every step. 86,400 becomes 100,000; 333,000 becomes 300,000. You're after the right power of ten, not the right digits.

Worked example: Snip

From 01.02 Functional and non-functional requirements: 10 million new links a month, and about 100 redirects for every link created. Assume each stored link (short code, long URL, owner, timestamps) takes about 500 bytes, and we keep links for five years.

Writes (creating links)

• 10 million a month ÷ 30 days ≈ 330,000 a day
• 330,000 ÷ 100,000 seconds ≈ 3–4 writes per second
• Peak at three times average: about 10 writes per second

Reads (redirects)

• 100 × the write rate ≈ 350 reads per second, about 1,000 at peak

Storage

• 10 million links a month × 12 months × 5 years = 600 million links
• 600 million × 500 bytes = 300 GB

Decide. Ten writes a second, a thousand reads a second and 300 GB of data: one ordinary database server handles that, with room to spare. Snip at this size doesn't need sharding, a message queue or a fleet of caches. We'd still add a second database copy so a single failure doesn't take redirects down (that's availability, from 01.03 Availability, durability, consistency, latency, cost), but scale isn't the problem.

Now multiply the traffic by a hundred: a billion new links a month. That's about 350 writes and 35,000 reads a second, and 30 TB over five years. Now the reads want a cache, and the data may need splitting across machines. Same system, different design, and the estimate is what told you.

Things people forget

• Peaks. Traffic follows the clock: evenings, launches, a link going viral. Design for peak, not average.
• Copies. If you keep three copies of every record for durability, storage is three times the raw number.
• Indexes and overhead. Databases store more than your raw rows. Adding 30–50% is a reasonable rough allowance.
• Growth. If traffic doubles each year, five years of data is mostly the last two years.

You don't need to apply all of these every time. Mention the ones that could change the decision.

Recap

Interview questions