Reference · gazar.dev ← hub

System design interviews · estimation

The estimation cheat sheet.

Only the numbers and formulas that actually earn points in a system design interview. The handful of values worth memorizing, the five formulas you run on every question, the capacity anchors you quote out loud, and three classic problems worked end to end. Skim it the night before; reach for it mid-whiteboard.

How to use numbers in the room

State every assumption out loud (“assume 100M DAU, 2 posts each”). The interviewer is grading the reasoning, not the digits.
Round hard. One significant figure, powers of ten. 86,400 → ~100,000. Nobody wants long division on a whiteboard.
Always do peak, not just average. Multiply average by a peak factor and design for that.
End each estimate with what it implies: “that’s read-heavy, so cache + replicas,” or “that won’t fit on one node, so shard.” The number is a means to a design decision.

The estimation flow

Run this same five-step sequence on every capacity question. Doing it in order, out loud, is most of the score.

Pin the assumptions

Ask for or assume DAU, actions per user per day, read:write ratio, average payload size, and retention. Write them in the corner of the board so you can reference them.

Compute QPS — average then peak

QPS = daily_actions ÷ 86,400 (≈ ÷100k). Then peak = avg × 2–10×. Split read QPS and write QPS, they drive different parts of the design.

Compute storage over the horizon

writes/day × size_each × days × replication. Use a 5-year horizon and ×3 replication. State the headline: “~X TB/year.”

Compute bandwidth & memory

Bandwidth = QPS × payload (read and write separately). Cache memory = hot_items × size, with the hot set ≈ the 20% serving 80% of traffic.

Translate to a decision

Turn numbers into machines and a bottleneck: number of cache nodes, shards, replicas; then name the one constraint that shapes the design (read-heavy → cache; write-heavy → shard; huge fan-out → hybrid).

The five formulas

Memorize these. Every estimation question is some combination of them.

QPS

avg QPS = daily_requests ÷ 86,400
peak QPS = avg QPS × peak_factor

86,400 s/day ≈ 100k, so 1M/day ≈ 12 QPS. Peak factor: 2× steady B2B, 5–10× consumer.

Storage

storage = writes/day × size_each
× retention_days × replication

Replication usually ×3. Add ~1.2–2× for indexes/metadata. Use a 5-year horizon.

Bandwidth

bandwidth = QPS × payload_bytes

Read and write separately. ×8 for bits/s. Egress is what shows on the cloud bill.

Cache memory

cache RAM = hot_items × size_each
hot_items ≈ 20% of total (80/20)

If the hot set fits in RAM across a few nodes, the DB barely sees read traffic.

Number of machines

machines = peak_QPS ÷ per_machine_QPS
or total_data ÷ per_machine_capacity

Size on peak; run at ~70%. Use the anchors in section 4 for per_machine_QPS.

QPS conversion table

1M / day	≈ 12 QPS
10M / day	≈ 115 QPS
100M / day	≈ 1.2k QPS
1B / day	≈ 11.6k QPS

Numbers to memorize

The constants that turn vague requirements into bytes and seconds. Learn these once and the arithmetic is fast.

Powers of two → data sizes

Power	Approx number	Size
2¹⁰	1 thousand	1 KB
2²⁰	1 million	1 MB
2³⁰	1 billion	1 GB
2⁴⁰	1 trillion	1 TB
2⁵⁰	1 quadrillion	1 PB

Availability → downtime / year

Nines	Downtime / yr	/ day
99%	3.65 days	14 min
99.9%	8.8 hours	86 s
99.99%	52.6 min	8.6 s
99.999%	5.3 min	0.86 s

Size of one thing

Item	Size
ASCII char	1 B
int / float	4 B
long / double / timestamp	8 B
UUID	16 B
Tweet / short post	~300 B–1 KB
Web page (HTML)	~100 KB
Photo (compressed)	~1–5 MB
Minute of 1080p video	~50 MB

Time & traffic constants

Quantity	Value
Seconds / day	86,400 ≈ 10⁵
Seconds / month	~2.6M
Peak factor (consumer)	×2–10
Replication factor	×3
Cache hit set (80/20)	~20% → 80%
Read:write (social)	~100:1

Capacity anchors

When you need to say “so we’d need N machines,” these are the safe round numbers to quote. They are deliberately conservative, exactly what an interviewer expects to hear.

Resource	Quote this	Use it to size…
App server throughput	~1,000 QPS	number of app/web servers
SQL database (per node)	~few k QPS	when to add read replicas / shard
Cache (Redis/Memcached)	~100k+ ops/s	cache tier size; absorbs read load
Message queue (per node)	~10k–100k msg/s	ingestion pipelines
RAM per machine	~64–256 GB	how many nodes to hold data in memory
SSD per machine	~few TB	how many nodes to store data on disk
Object store (S3-like)	effectively ∞	blobs, media, backups, logs

The three levers, and when each kicks in

Cache when reads >> writes (the 80/20 rule means a small cache absorbs most reads). Replicate when you need read scale or availability (replicas serve reads; one primary takes writes). Shard when the data or the write load outgrows a single node. Most designs use all three.

Per-tool scaling: the wall and the next move

The interviewer’s favourite follow-up is “now it grows 10×, what breaks?” Each card leads with the numbers: 1 node what a single node handles, scale when the threshold that forces a move, breaks what goes wrong, next the move and how much more it buys. Compare your estimate against the “1 node” figure to decide one box vs many.

SQL DB — Postgres / MySQLsource of truth

1 node: ~5k–20k reads/s · ~1k–5k writes/s · hot set ≤ RAM (~64–256 GB) · ≤ ~few TB disk · ~300–500 conns
Scale when: writes > ~5k/s, conns > ~500, or hot data > one node’s RAM
Breaks: write latency & replication lag climb; connection errors; disk-bound queries slow 10–100×.
Next: Read replicas (each +1 node of read QPS) → pooler (conns → thousands) → cache → shard (writes scale ~linearly with shards), costing cross-shard joins.

Rediscache / in-memory

1 node: ~100k ops/s (500k+ pipelined) · practical RAM ~10s–100+ GB · ~50–100 B overhead/key · 10k conns (≤65k)
Scale when: data > node RAM, ops > ~100k/s, or any O(n) command (KEYS, big union)
Breaks: evictions spike misses → DB load jumps; OOM; one slow command stalls every request.
Next: Redis Cluster (up to ~1000 nodes → millions ops/s, TBs RAM, near-linear); replicas for read scale & HA.

MongoDBdocument store

1 node: ~10k–50k ops/s (working set cached) · WiredTiger cache ~50% of RAM · 1 primary takes writes
Scale when: working set > ~50% RAM, or writes > one primary (~few k/s)
Breaks: reads fall to disk and slow; write contention on the primary; a bad shard key hot-spots one shard.
Next: Shard on a high-cardinality, non-sequential key (near-linear with shards); read secondaries if eventual consistency is fine.

Cassandra / DynamoDBwide-column / KV

1 node / part.: ~10k–50k writes/s per node · Dynamo partition cap ~1k writes / ~3k reads per second
Scale when: a single key/partition > ~1k–3k ops/s (hot partition), or you need joins / ad-hoc queries
Breaks: one key → hot node / throttling; the query you need isn’t supported by the schema.
Next: Add nodes (near-linear; clusters reach 100s–1000s of nodes, millions writes/s); redesign the partition key; one table per access pattern.

Kafkalog / queue

1 broker: ~100s MB/s · ~10 MB/s per partition · keep < ~1k–4k partitions/broker · consumers ≤ partition count
Scale when: consumer lag grows, throughput > broker disk, or partitions/broker > ~few k
Breaks: lag → end-to-end delay balloons; broker disk saturates; recovery & leader election slow.
Next: Add partitions + consumers (parallel throughput) & brokers → cluster does millions msgs/s. Plan partitions ahead.

Elasticsearchsearch index

1 node: heap ≤ ~32 GB · shard 10–50 GB (or ~200M docs) · ~20 shards/GB heap (~600 cap) · 100s–1k queries/s
Scale when: a shard > 50 GB, index > file cache, or heavy aggregations cause GC pauses
Breaks: GC pauses & heap pressure from too many shards; queries slow once the index outgrows RAM.
Next: More nodes & shards; hot/warm tiering for old data; keep ES as a derived index, never the only copy.

Object store (S3-like)blobs / media

per prefix: ~3,500 PUT/s & ~5,500 GET/s per prefix · ~10s–100s ms latency · capacity effectively unlimited
Scale when: requests on one prefix > ~3.5k write / ~5.5k read per s, or you need block-storage latency
Breaks: a hot prefix returns slow-down / 503 errors; latency-sensitive reads feel sluggish.
Next: Spread keys across prefixes (throughput scales ~linearly with prefixes); put a CDN / cache in front for hot reads.

The pattern behind all of them

Almost every “what breaks” answer is one of three: writes exceed one node → shard; reads exceed one node → replicate or cache; data exceeds one node’s RAM/disk → shard or tier. The tool changes; the moves do not. Say the move and the trade-off it costs, and you have answered the question.

Worked problems

The classics, run through the exact five-step flow. Notice the rounding: one significant figure the whole way.

URL shortener (TinyURL)

100M new URLs/day · 100:1 read:write

Write QPS: 100M ÷ 100k ≈ 1,000/s avg, ~5,000/s peak.
Read QPS: 100× → ~100k/s avg, ~500k/s peak. read-heavy
Storage: ~500 B × 100M/day × 365 × 5 × 3 ≈ ~270 TB over 5 years.
Keys: 100M/day × 1,825 days ≈ ~180B URLs → base62 length 7 (≈ 3.5T) is plenty.
Decision: read-heavy → cache hot URLs in Redis; reads almost never touch the DB.

Shape: trivial write path, cache-first read path. Not a hard problem at scale.

Social news feed (Twitter)

200M DAU · 2 posts/user/day · ~200 followers avg

Write QPS: 200M × 2 ÷ 100k ≈ ~4,000 posts/s, ~20k/s peak.
Read QPS: feed opened ~10×/day → 2B/day → ~20k/s avg, ~100k/s peak.
Fan-out on write: each post × 200 followers → ~800k feed writes/s. the real cost
Celebrity problem: a user with 50M followers explodes fan-out → hybrid: fan-out on write for normal users, fan-out on read for celebrities.
Decision: the fan-out model is the design; precompute feeds in a cache.

Shape: cost is fan-out, not raw posts. The celebrity tail forces the hybrid model.

Chat / messaging (WhatsApp)

500M DAU · 40 messages/user/day · ~100 B each

Write QPS: 500M × 40 ÷ 100k ≈ ~200k msg/s, ~1M/s peak. write-heavy
Storage: 100 B × 20B msg/day × 365 × 3 ≈ ~2 PB/year (less if messages expire).
Bandwidth: 200k/s × 100 B ≈ ~20 MB/s — tiny; the load is op count, not bytes.
Connections: 500M users hold persistent connections → need many gateway nodes + a presence system.
Decision: write-heavy + huge connection count → shard by user/conversation; queue for delivery.

Shape: high op-rate, small payloads, persistent connections. Shard and queue.

Video streaming (YouTube)

500 h uploaded/min · ~5B views/day

View QPS: 5B ÷ 100k ≈ ~50k/s avg, ~250k/s peak (metadata calls).
Storage: 500 h/min → transcoded to many formats ~100 MB/min → ~3 TB/min → ~4 PB/day. storage-dominated
Egress: peak concurrent ~10M streams × ~5 Mbps ≈ ~50 Tbps. No origin serves this. CDN-dominated
Tiers: blobs in object store, ~99% of bytes from a CDN, metadata in a sharded DB.
Decision: async transcoding pipeline (queue + workers); CDN is the whole game.

Shape: bytes, not QPS. Object store + CDN + async transcode.

Photo sharing (Instagram)

500M DAU · 100M photos/day · ~100:1 read:write

Write QPS: 100M ÷ 100k ≈ ~1k/s, ~5k/s peak.
Storage: ~2 MB photo + thumbnails ~3 MB × 100M/day ≈ ~300 TB/day → ~100 PB/yr in object store.
Read QPS: ~100× → ~100k/s avg; images served from CDN, not the app.
Feed: same fan-out / celebrity split as Twitter → precompute feeds in cache.
Decision: object store + CDN for media; metadata DB sharded by user; hybrid feed.

Shape: Twitter feed + heavy media storage. CDN for images.

Ride-sharing (Uber)

~10M active drivers · location ping every 4 s · 1M rides/day

Location writes: 10M ÷ 4 s ≈ ~2.5M updates/s. way past any SQL node
So: locations are ephemeral, hold them in memory (geo-index), not a durable DB.
Matching reads: “drivers near me” → spatial query on a geohash / QuadTree index, sharded by region.
Durable data: 1M rides/day ≈ ~12/s, tiny → ordinary sharded DB.
Decision: in-memory geo-index sharded by city handles the 2.5M/s; DB only for ride records.

Shape: firehose of ephemeral writes → in-memory + geo-sharding, not a DB.

File storage / sync (Dropbox)

500M users · ~10 GB stored each · sync across devices

Storage: 500M × 10 GB ≈ ~5 EB raw. storage-dominated
Dedup: chunk files into blocks + hash; identical blocks stored once → cuts real storage 2–10×.
Metadata: file → block map per user in a sharded DB (by user); the heavy bytes live in object store.
Sync: on change, push a notification; clients pull only changed blocks.
Decision: chunk + dedup into object store; metadata DB sharded by user; notify-then-pull sync.

Shape: storage + dedup + metadata. Blocks in object store, map in DB.

Web crawler

crawl ~1B pages/day · ~100 KB/page · re-crawl for freshness

Fetch rate: 1B ÷ 100k ≈ ~10k pages/s across a worker fleet.
Bandwidth: 10k/s × 100 KB ≈ ~1 GB/s ingest.
Storage: 100 KB × 1B/day ≈ 100 TB/day raw, ~30 TB/day compressed → object store.
Dedup URLs: the “seen” set is billions → a bloom filter in memory instead of a giant DB lookup.
Decision: URL frontier queue + worker fleet; bloom filter for seen; politeness per domain; pages to object store.

Shape: throughput + a huge dedup set → queue, workers, bloom filter.

Rate limiter

~1M API req/s · per-user limit · must add < 1 ms

Checks: one per request → ~1M counter ops/s.
One Redis node does ~100k ops/s → 1M ÷ 100k = ~10 nodes. shard the counters
Memory: a counter per active user is tiny (~tens of bytes) → tens of millions of users fit easily in RAM.
Algorithm: token bucket or sliding window via atomic INCR + TTL.
Decision: sharded Redis counters, or per-node local counters with approximate sync to shave the network hop.

Shape: 1M ops/s > one Redis node → shard; counters are memory-cheap.

Latency numbers

You rarely calculate with these, but they justify your design choices: why cache (memory vs disk), why a CDN (cross-region), why colocate (same-DC vs cross-ocean). Know the orders of magnitude.

Operation	Latency	Why it matters in design
Read from memory (RAM)	~100 ns	why caches exist
Read 1 MB from RAM	~5 µs	in-memory is “free”
SSD random read	~100 µs	~1000× slower than RAM → cache hot data
Round trip, same datacenter	~500 µs	keep chatty services colocated
Read 1 MB from SSD	~1 ms	disk is fine for cold/bulk
HDD seek	~10 ms	avoid random disk on the hot path
Round trip, cross-continent	~150 ms	why CDNs & regional replicas exist

The one-liner to remember: memory ~100× faster than SSD; SSD ~100× faster than crossing an ocean. Every network hop you remove is worth more than a thousand code optimizations.

Sources & further reading: ByteByteGo: Back-of-the-envelope · systemdesign.one · Latency Numbers Every Programmer Should Know (jboner) · System Design Primer. Figures are deliberately rounded; in an interview the reasoning matters more than the exact digits.