Capacity estimation for system design interviews

1. What capacity estimation is

Back-of-envelope estimation is quick, approximate arithmetic about load and resources: how many requests a second, how many bytes stored over five years, how much bandwidth out of the data center, how much memory a cache needs. It is deliberately rough. The aim is the right order of magnitude, because a system handling 100 writes a second and one handling 100,000 are built differently, while 2,300 and 2,500 are not.

2. Why interviewers ask for it

Estimates are where a design stops being generic. Interviewers want to see that your choices follow from numbers: that you partition the store because the data will not fit on one machine, or add a cache because the read rate is high and the hot set is small. They also watch how you handle uncertainty. Stating an assumption, rounding it, and moving on is a skill; spending ten minutes on exact multiplication is a mistake.

Most interviewers do not check your arithmetic to the digit. They do notice a missing factor of 1,000 or a confusion between bits and bytes, because those change the design.

3. The numbers to memorize

seconds per day    = 24 x 60 x 60   = 86,400      (call it 10^5)
seconds per month  = 30 x 86,400    = 2,592,000   (about 2.6 million)
seconds per year   = 365 x 86,400   = 31,536,000  (about 3 x 10^7)

1 million a day    / 86,400  = about 12 a second
100 million a day  / 86,400  = about 1,160 a second
1 billion a day    / 86,400  = about 11,600 a second

Using 10^5 for a day understates the rate by about 14%, since 86,400 / 100,000 = 0.864. That is well inside the error of any estimate, but say which you used so the interviewer can follow.

4. From users to requests a second

average QPS = daily active users x actions per user per day / 86,400
peak QPS    = average QPS x peak factor
read QPS    = write QPS x reads per write

Example (assumed): 10 million DAU x 20 actions = 200 million a day
  200,000,000 / 86,400 = about 2,300 a second on average
  x 3 for peak         = about 7,000 a second

Peak factor. Traffic is not flat. A factor of 2 to 3 over the daily average is a common assumption for consumer products with a daily cycle. Use 10 or more for event-driven spikes: a sale opening, a live final, a push campaign. Say why you picked the number.

Read/write ratio. Most consumer systems read far more than they write: 10 to 1 for a URL shortener, 100 to 1 or more for a social feed. The ratio decides where you spend effort. A read-heavy system wants caches and replicas; a write-heavy one wants partitioning, batching and append-friendly storage.

5. Storage, bandwidth and memory

storage   = writes per day x bytes per write x days retained x replication factor
bandwidth = requests per second x bytes per request x 8   (bits per second)
cache     = hot items x bytes per item x overhead (about 1.5 for keys and allocator)

• Storage. Add a replication factor (3 is a common default) and, for databases, room for indexes. Keep media separate from metadata: they live in different stores and grow at different rates.
• Bandwidth. Network links are quoted in bits a second, storage in bytes. Multiply by 8 when you go from bytes to bits. Egress (data out) is usually the larger and the more expensive.
• Cache memory. You rarely cache everything. If 20% of items get most of the reads (a common assumption, not a law), size the cache for that 20%. See caching for how to derive it.

6. Latency numbers every engineer should know

The figures below come from the widely circulated list popularized by Jeff Dean and Peter Norvig. Treat them as approximate orders of magnitude: hardware has moved on since they were compiled (memory and SSDs are faster, data center networks are quicker), but the gaps between the rows are what matter, and those still hold.

• Memory is about a thousand times faster than a random SSD read (100 ns against 150 µs). That is why hot data belongs in RAM.
• A network hop costs far more than memory. A cache on another machine is fast because it avoids disk, but each lookup still pays a round trip of a few hundred microseconds. Ten sequential calls add up; parallelize or batch them.
• Distance is fixed by physics. An intercontinental round trip takes on the order of 100 ms however good the hardware, so a user-facing request can afford very few of them. Put data and caches near users.

7. Worked examples from common prompts

Each example states its assumptions first. They are illustrative figures for practice, not any company's real traffic.

A Twitter-style home timeline

posts:     200M x 0.5 = 100M a day   / 86,400 = about 1,160 a second  (peak x3: about 3,500)
reads:     200M x 10  = 2B a day     / 86,400 = about 23,000 a second (peak x3: about 70,000)
storage:   100M x 500 B = 50 GB a day; x 365 = about 18 TB a year; x 3 replicas = about 55 TB
fan-out:   100M posts x 200 followers = 20B timeline inserts a day = about 231,000 a second
cache:     200M timelines x 800 post IDs x 8 B = 1.28 TB

The numbers point at the design. Fan-out on write multiplies each post by 200, so timeline writes outnumber posts by two orders of magnitude, which is why accounts with millions of followers get special handling. A 1.3 TB timeline cache needs a cluster: about 20 nodes at 64 GB each, before replicas. See design Twitter.

Video streaming bandwidth

egress:    10M streams x 5 Mbps = 50,000,000 Mbps = 50 Tbps  (= 6.25 TB a second)
per hour:  40 Mbps x 3,600 s / 8 = 18,000 MB = 18 GB of files per content hour
catalog:   10,000 hours x 18 GB = 180 TB
servers:   50 Tbps / 100 Gbps per server = 500 servers at full load (assumed capacity)

Storage is modest; bandwidth is the whole problem. 50 Tbps cannot come from one site, so the design is about pushing popular titles to edge caches close to viewers and keeping the origin for the long tail. See design Netflix.

A chat service

messages:     500M x 50 = 25B a day / 86,400 = about 290,000 a second (peak x2: about 580,000)
storage:      25B x 200 B = 5 TB a day; kept 30 days = 150 TB; x 3 replicas = 450 TB
connections:  500M x 0.3 = 150M open connections / 100,000 = 1,500 gateway servers
memory:       150M x 10 KB = 1.5 TB across the fleet, about 1 GB a server

Here the hard numbers are concurrent connections and message throughput, not bytes. That steers the deep dive toward the connection gateways, routing a message to the server holding the recipient's connection, and partitioning messages by conversation. See design WhatsApp.

Smaller prompts follow the same pattern: the URL shortener estimate shows a 10 to 1 read ratio, and the rate limiter estimate is about counter memory per client.

8. Mistakes to avoid

• Bits versus bytes. 5 Mbps is 0.625 MB a second. Mixing them is an error of 8 times.
• Forgetting peak. Systems are sized for the busy hour, not the daily average.
• Forgetting replication and indexes. Raw data x 3 replicas, plus index space, is what you buy.
• Losing zeros. Write numbers in powers of ten: 2 x 10^9 / 10^5 = 2 x 10^4. It is much harder to drop a factor of 1,000 that way.
• False precision. "23,148 requests a second" suggests a certainty you do not have. Say "about 23,000".
• Worrying about 1,000 versus 1,024. The difference is 2.4%. Ignore it.
• Averaging a skewed load. The average per user hides hot keys: a celebrity account or a viral link concentrates traffic on one partition.
• Estimates that change nothing. If no number influenced a decision, the estimate was decoration.

9. How to talk about it in the interview

• Ask whether the interviewer wants estimates at all. Some prefer you skip straight to design; most like a short pass.
• Say every assumption before using it, and round as you go.
• Finish each number with its consequence: "so this fits in memory", "so we need to partition", "so the network, not storage, is the limit".
• Write the results in a corner of the board and point back to them when you make choices later.

The arithmetic, for checking: 50 million / 10 = 5 million uploads a day, and 5 million / 86,400 is about 58 a second. 50 million x 50 = 2.5 billion views, and 2.5 billion / 86,400 is about 28,900 a second. 5 TB x 365 = 1,825 TB. 28,900 x 1 MB x 8 = about 231 Gbps.

Practicing with Natively

Estimates are easy on paper and hard out loud, under time pressure. Practice them in a mock interview: Natively transcribes the conversation live, so afterwards you can read back exactly which assumptions you stated and where a number went unused. During practice it can suggest talking points for each question as it comes in; comparing them with what you said is a quick way to spot gaps such as peak traffic or replication, and it can explain a screenshot you capture of an estimate or a problem statement. The transcript and notes are kept for review after the session.