Estimation | System Design Interview Handbook

🧮

Why Estimate at All

the 5-minute sanity check

Estimation is how you find the bottleneck before you draw around it. A number tells you whether the data fits in memory or needs a hundred machines, whether reads or writes dominate, whether the payload is the story or the request count is. Skip it and you're designing blind, and the interviewer knows it.

The goal is not precision. It's the right order of magnitude, fast, so the rest of your design rests on something real. "It should scale" is not an answer. "That's 4 GB/s of egress, so this is a CDN problem, not a database problem" is.

💡

You only need three outputs from this stage: peak QPS, total storage, and peak bandwidth. Everything you compute is in service of one of those three. Say each number out loud with its unit, then move on.

🔢

Numbers to Memorize

powers · latency · throughput · time

You can't derive these in the room, so carry them in. Four small tables cover almost every question. Round everything; the point is the ratio between numbers, not the numbers themselves.

Powers of two → data sizes Sizing

Power	≈ Value	Name
2^10	1 thousand	Kilobyte (KB)
2^20	1 million	Megabyte (MB)
2^30	1 billion	Gigabyte (GB)
2^40	1 trillion	Terabyte (TB)
2^50	1 quadrillion	Petabyte (PB)

Latency numbers, rounded Every engineer should know

Operation	Time	What it tells you
L1 cache reference	1 ns	The floor. Everything is measured against this.
Main memory reference	100 ns	~100× slower than L1, still effectively free.
Read 1 MB from memory	250 µs	RAM is fast but not infinite; big scans still cost.
SSD random read	100 µs	~1000× slower than memory. Cache to avoid it.
Read 1 MB from SSD	1 ms	~4× the memory read. SSD is closer to RAM than to disk.
Datacenter round trip	0.5 ms	A network hop inside one region is cheap.
Disk seek (rotational)	10 ms	~100,000× a memory reference. Random disk I/O is death.
Read 1 MB from disk	20 ms	Sequential disk is tolerable; random is not.
Round trip US ↔ Europe	150 ms	Cross-region on the request path is poison.

Throughput rules of thumb Capacity

Resource	Rough ceiling
App server (simple req)	~10K QPS
SSD	~100K IOPS, ~1 GB/s
DB primary (writes)	~a few K/s
Redis / cache node	~100K ops/s
1 Gbps link	~125 MB/s
10 Gbps link	~1.25 GB/s

Time, rounded The key trick

Interval	Seconds
Per day	86,400 → 100K
Per month	~2.5 million
Per year	~30 million

Rounding a day to 10⁵ seconds is the single most useful move in this whole page. It turns "requests per day ÷ seconds per day" into a clean shift of the decimal point.

ℹ️

The exact values drift with hardware, and nobody grades you on 100 µs vs 150 µs. What you're being tested on is the ratios: memory is ~1000× faster than SSD, SSD is ~10× faster than disk seeks, a cross-region hop is ~300× a local one. Those gaps decide architecture.

⚡

Estimating QPS

DAU → average → peak

The derivation is always the same four steps: start from daily active users, multiply by how many times each one hits the feature per day, divide by seconds per day for the average, then multiply by a peak factor because traffic is never flat.

  ┌──────────┐     ┌──────────────┐     ┌─────────────┐     ┌──────────┐     ┌──────────┐
  │  100M    │  ×  │  5 requests  │  =  │  500M reqs  │  ÷  │ 100K sec │  =  │ 5K QPS   │
  │   DAU    │     │ per user/day │     │  per day    │     │ per day  │     │ average  │
  └──────────┘     └──────────────┘     └─────────────┘     └──────────┘     └────┬─────┘
                                                                                  │
                                            peak factor ×2 to ×5 (here ×3)        │
                                                                                  ▼
                                                                            ┌──────────┐
                                                                            │ 15K QPS  │
                                                                            │   peak   │
                                                                            └──────────┘

Worked example: a social feed Step by step

DAU: 100M users open the app on a given day.
Actions per user: each refreshes the feed ~5 times → 500M feed reads/day.
Average QPS: 500M ÷ 100K seconds = 5,000 QPS.
Peak QPS: traffic clusters around evenings and events, so ×3 → 15,000 QPS.
Sanity check: one app server handles ~10K simple QPS, so this is a handful of machines plus headroom, not a heroic system. That feels right for a read of a cached feed.

⚠️

The peak multiplier is where designs quietly break. Average load provisions nothing useful, because your system dies at the peak, not the mean. Pick 2× for smooth global traffic, 5× or more for spiky, event-driven, or timezone-clustered load. State which and why.

💡

Separate read QPS from write QPS from the start. A 100:1 read/write ratio is the tell that this is a caching and read-replica problem (Caching), while a write-dominated number pushes you toward sharding and queues (Sharding). The ratio shapes the whole design, so surface it here (Design Process).

💾

Estimating Storage

size × rate × retention × replicas

Storage is a multiplication: how big each object is, times how many you write per day, times how long you keep them, times how many copies you hold. The trap is treating all data as one number. Split it: small metadata scales differently from large payloads, and one of them usually dwarfs the other.

  writes/day        object size        retention           replication
  200M tweets   ×   500 bytes     ×    365 days      ×      3 copies
       │                │                  │                    │
       └──── 100 GB/day ┘                  │                    │
                 └─────────── 36 TB/year ──┘                    │
                                     └──────────── ~110 TB stored ┘

Worked example: tweets for a year Metadata vs payload

Text and metadata. 100M users post ~2 tweets/day → 200M tweets/day. Text plus IDs, timestamps and user reference is ~500 bytes.

Per day: 200M × 500 B = 100 GB/day.
Per year: 100 GB × 365 ≈ 36 TB/year.
With 3× replication (Replication): ≈ 110 TB. Fits on a modest cluster.

Media. Say 10% of tweets carry a 200 KB image → 20M images/day.

Per day: 20M × 200 KB = 4 TB/day.
Per year: ≈ 1.5 PB/year, and ≈ 4.4 PB replicated.

The image bytes are 40× the text bytes. This design is a blob-storage-and-CDN problem wearing a database costume. Say that out loud, then keep media out of the database entirely (Specialized Stores).

💡

This is the moment to name the real bottleneck. When payload dwarfs metadata, the interviewer is watching for whether you split them: metadata in a database, payload in object storage with a pointer, delivery through a CDN. Candidates who store image bytes in Postgres lose the thread here.

📶

Bandwidth & Memory

ingress · egress · cache sizing

Bandwidth falls straight out of the storage math: a per-day byte total divided by seconds per day is a byte rate. Split it two ways. Ingress is what you take in (roughly your write volume). Egress is what you serve out, and on a read-heavy system it's larger by the read/write ratio.

Bandwidth from the tweet example Ingress vs egress

Flow	Rate	Consequence
Text ingress	1 MB/s	100 GB/day ÷ 100K s. Trivial.
Media ingress	40 MB/s	4 TB/day ÷ 100K s. One fat link handles it.
Media egress (100:1 reads)	4 GB/s	40 MB/s × 100. No origin serves this; you need a CDN.

ℹ️

Egress is where cost lives. Reads outnumber writes, payloads leave more often than they arrive, and cross-region or internet egress is billed. The 4 GB/s number is the argument for pushing bytes to the edge and never touching origin on a cache hit (Networking Basics).

Cache sizing with the 80/20 rule Memory

You rarely cache everything. Roughly 20% of the data serves 80% of the reads: recent tweets, popular items, active users. Size the cache to the hot set, not the corpus.

Daily text written: ~100 GB. The hot working set that reads actually touch is a fraction of that.
Cache the hot 20% ≈ 20 GB, which fits in the RAM of a single cache node with room to spare.
Lesson: for small-payload, read-heavy systems, the working set fits in memory. That's the same insight that makes a URL shortener cheap, and it's why caching is the highest-leverage move you have.

✂️

Rounding Discipline

round hard, keep units

How to keep the math cheap and honest Discipline

Round to one significant figure. 86,400 becomes 100K, 365 becomes 400 (or just leave the year as ~30M seconds). You're finding the order of magnitude, not balancing a ledger.
Keep units on every line. Bytes/day, GB, QPS, MB/s. Half of all estimation errors are a lost factor of 1000 from dropping a unit. The unit is the error check.
Carry powers of ten, not commas. 500M is 5 × 10⁸; 100K seconds is 10⁵. Dividing is subtracting exponents: 10⁸ ÷ 10⁵ = 10³ = a few thousand QPS.
Sanity-check against a known ceiling. 15K peak QPS against ~10K per server means a few machines. 4 GB/s egress against a 1.25 GB/s link means it cannot be one origin. The check catches the dropped-1000 error instantly.
Stop when the number decides the design. Once you know it's "TB not PB" or "CDN not database," the estimate has done its job. More digits are theater.

⚠️

Precision is a trap that eats interview minutes. Nobody wants 4.38 PB; they want "single-digit petabytes, so object storage, tiered, with lifecycle expiry." Spend the time you saved on the design, which is what's actually being graded.

📋

Quick Reference

the numbers on one card

Memorized numbers Carry these in

Quantity	Value	Note
Seconds/day	~100K (10^5)	The workhorse. Round 86,400 up.
Seconds/year	~30M	For retention math.
KB / MB / GB / TB / PB	10^3 … 10^15	Each step is ×1000.
Memory reference	100 ns	Effectively free.
SSD random read	100 µs	~1000× memory.
Disk seek	10 ms	Avoid random disk I/O.
Same-region round trip	0.5 ms	Cheap.
Cross-region round trip	~150 ms	Never sync on the request path.
App server	~10K QPS	Divide peak QPS by this for fleet size.
1 / 10 Gbps link	125 / 1250 MB/s	Check egress against this.

The standard derivations Formulas

Target	Formula	Then
Average QPS	DAU × req/user ÷ 100K	× 2–5 for peak
Fleet size	peak QPS ÷ ~10K	+ headroom & redundancy
Storage/year	obj size × writes/day × 365	× ~3 for replicas
Ingress	bytes written/day ÷ 100K	≈ write bandwidth
Egress	ingress × read/write ratio	> link capacity → CDN
Cache size	hot-set bytes (~20% of daily)	fit in RAM if you can

Back-of-Envelope Estimation

Why Estimate at All

Numbers to Memorize

Estimating QPS

Estimating Storage

Bandwidth & Memory

Rounding Discipline

Quick Reference