How do you do capacity planning and back-of-the-envelope estimation for a new system?

#This isn't a math test — it's a judgment test

Back-of-the-envelope estimation shows up in almost every system design interview, and the biggest misconception about it is that you're being graded on arithmetic precision. You're not. The interviewer is watching for three things: whether you state your assumptions explicitly instead of pulling numbers from nowhere, whether your units stay consistent as you chain calculations together, and whether the resulting number would actually change a design decision (e.g., "do we need sharding on day one, or does a single beefy Postgres? instance survive for two years?").

A good estimate is round, defensible, and fast. A bad estimate is precise, unexplained, and slow — nobody needs "14,237.8 requests per second" when "roughly 15K RPS, let's say 20K to be safe" drives the same design decisions in a third of the time.

#The framework

Work through layers in this order, because each one feeds the next:

1. Clarify scope — read-heavy or write-heavy? What's the retention period? What's a reasonable growth horizon (most interviews want 1-3 years, not 10)?
2. Traffic (QPS) — convert a business-level number (signups/day, posts/day) into requests per second, for both average and peak load.
3. Storage — per-record size times record count times retention period times replication factor.
4. Bandwidth — QPS times average payload size, separately for ingress and egress.
5. Memory / cache — what fraction of traffic can a cache absorb, and how big does that cache need to be?
6. Servers — given a single instance's realistic throughput, how many instances does the estimated load require?

#Worked example: a URL-shortening service

Assumptions (state these out loud first):

Step 1 — Write QPS. A month is roughly 30 x 24 x 3600 ≈ 2.6 million seconds. 500,000,000 / 2,600,000 ≈ ~190 writes/sec average. Applying the 3x peak factor gives ~570 writes/sec peak.

Step 2 — Read QPS. With a 100:1 read:write ratio: 190 x 100 = ~19,000 reads/sec average, and roughly ~57,000 reads/sec peak.

Step 3 — Storage. 500M records/month x 500 bytes ≈ 250 GB/month of new data. Over 5 years (60 months): 250 GB x 60 ≈ 15 TB of raw data. With 3x replication for durability: ~45 TB total.

Step 4 — Bandwidth. Egress at peak: 57,000 reads/sec x (say) 1 KB average response (a redirect plus headers) ≈ ~57 MB/sec egress. That's a number worth sanity-checking against a CDN's typical throughput per edge node — it tells you almost immediately whether this fits comfortably behind a CDN or needs dedicated capacity.

Step 5 — Cache sizing. Real-world link access follows a power law — a small fraction of links get most of the redirects. If the hot 20% of daily-active short codes account for 80% of reads (a classic 80/20 split), caching that hot set in something like Redis means: at, say, 10 million daily-active links, 20% is 2 million entries x ~100 bytes (just the code to long-URL mapping, not the full record) ≈ ~200 MB — trivially cacheable in memory on a single node, with room to spare for replicas.

Step 6 — Servers. If one application server handles roughly 5,000 requests/sec comfortably, peak read load of ~57,000/sec needs on the order of 12 instances, before adding headroom for failover and rolling deploys — so round up to 15-18.

#Handy mental-math shortcuts

• A day has ~86,400 seconds — round to 100,000 for fast mental division (introduces ~15% error, which is fine at this level of precision).
• A month is ~2.6 million seconds, a year is ~31.5 million seconds (~3.15 x 10^7) — worth memorizing outright.
• Powers of two for storage: 2^10 ≈ 10^3 (KB), 2^20 ≈ 10^6 (MB), 2^30 ≈ 10^9 (GB), 2^40 ≈ 10^12 (TB) — treating them as equal is the standard, accepted shortcut in these interviews.
• 1 million requests/day ≈ 12 requests/sec average — a number worth memorizing since so many prompts start with a daily active user count.

#Pitfalls that cost more than a wrong number

Other common misses: forgetting metadata/index overhead (a database rarely stores just your raw bytes — indexes, WAL, and replication logs add real overhead, often 20-50%), and over-indexing on precision (spending three minutes multiplying 4-digit numbers by hand instead of rounding to one significant figure and moving on to the design decision the number was supposed to inform).

🧠 Check your understanding
0/3 · 0/3 answered
1. What is the primary thing interviewers are evaluating in a back-of-the-envelope estimation exercise?
Whether the candidate can multiply large numbers quickly without a calculatorWhether the final numeric answer matches a memorized reference value exactlyWhether the candidate knows the exact current pricing of cloud storageWhether assumptions are stated explicitly, units stay consistent, and the result would influence a real design decision
2. Why is forgetting the peak-to-average traffic ratio a serious estimation mistake?
Peak traffic is always exactly double average traffic in every systemProvisioning only for average load means the system fails exactly when load spikes matter mostIt has no real effect on infrastructure sizingIt makes the math take longer to compute
3. When estimating storage for a durable system, why must the replication factor be applied on top of raw data size?
The raw data size already accounts for all copies needed for durabilityReplication factor is only relevant for read-heavy systemsReplication factor only matters for compute, not storageActual disk provisioned must cover every replica of the data, not just one logical copy, so raw size understates real infrastructure needs by the replication multiple