Concepts / Fundamentals / Back-of-the-envelope capacity planning

Back-of-the-envelope capacity planning

Turning users and bytes into machines, with arithmetic an interviewer can follow.

System design conceptFundamentals1 Nov 2026

01The intuition

The problem it solves

A wedding planner is told "about 600 guests". She does not design the hall from that number alone. She works it out: 600 guests, 10 per table, so 60 tables; a table needs 10 square metres, so 600 square metres plus aisles; dinner for 600 in two hours at 20 plates a minute per serving line needs 5 lines. Every choice downstream comes from a few multiplications that anyone at the table can check.

System design interviews expect the same. "Design YouTube" means nothing until you know roughly how many uploads a day, how many bytes each, and how many views. Back-of-the-envelope planning turns the vague prompt into machines, disks and bandwidth, and it tells you which part of the design is actually hard.

Build it one piece at a time

Step 1: start from people. Ask or assume daily active users. Say 100 million for a video site.

Step 2: turn people into requests. Each user watches 5 videos a day: 500 million views a day. A day has 86,400 seconds, call it 105 for arithmetic:

500,000,000 ÷ 100,000 ≈ 5,000 views per second on average; peak is 2 to 3 times that, so plan for 15,000

Step 3: turn requests into bytes. A view streams 5 minutes at 3 Mbit/s, so 112 MB per view; 15,000 views a second in progress means about 15,000 × 3 Mbit/s ≈ 45 Gbit/s leaving the edge.

Step 4: turn uploads into storage. One in a hundred users uploads a video a day: 1 million uploads, 200 MB each after transcoding into renditions, so 200 TB a day, 73 PB a year. With three copies, 220 PB a year.

QuantityValueWhat it decides
views per second (peak)15,000how many serving machines and how big the cache must be
egress45 Gbit/sa CDN is mandatory; origin cannot serve this
new storage per year220 PBobject storage, not a database; tiered to cheap disks
metadata rows per year365 millionfits one sharded database comfortably

Step 5: turn bytes into machines. A machine with 10 Gbit/s of network serves about 3,000 concurrent 3 Mbit/s streams; 15,000 streams need 5 machines of pure bandwidth, but with caching and headroom you would run 20. A 20 TB disk holds 100 of your transcoded videos; 220 PB a year is 11,000 disks a year, which is why cold videos move to cheaper storage.

Why it works, with the numbers

The useful constants fit on a card: 105 seconds in a day, 2.6 million seconds in a month, a character is a byte, an int is 8 bytes, a disk reads about 100 MB/s, memory reads about 10 GB/s, a data-centre round trip is under 1 ms, a cross-continent one is 100 to 250 ms, one machine handles roughly 1,000 to 10,000 simple requests a second. With those, every number above is two multiplications, and an interviewer can follow each one.

The rule is to compute only what changes a decision. The egress number decided "CDN"; the storage number decided "object store with tiers"; the metadata number decided "an ordinary database is fine". Numbers that decide nothing are noise. The failure mode is false precision: 3.47 machines is wrong, "about 4, run 6" is right, and forgetting the peak-to-average factor or the replication factor is the most common slip.

The trade-off you must say out loud

Estimates are assumptions with arithmetic attached. Say the assumptions first ("I am assuming 100 million daily users and 5 views each") so the interviewer can correct them before you build on them. Google's SRE loops take this further with NALSD (non-abstract large system design) rounds, where you are given hardware specs and must say how many of that exact machine you need and why. The follow-up is always "what if that number is ten times bigger?", and your design should name the first part that breaks.

Where it shows up in the 100 Google problems

02Used in these problems