Estimation Drills

Estimation is a motor skill. Reading a worked example is not the same as producing one under time pressure, so work these with a pen before reading the answers.

Drill A: URL shortener

Design a URL shortener handling 100 million new URLs per day with a 10:1 read-to-write ratio. Estimate QPS and five-year storage.

Assumptions to state: ~500 bytes per record (long URL, short code, metadata, timestamps), 5-year retention, 3x replication.

Write QPS   = 100M / 86,400            = ~1,200/sec
Read QPS    = 10 * 1,200               = ~12,000/sec
Peak (3x)   = 3 * 12,000               = ~36,000 reads/sec

Storage/day = 100M * 500 B             = 50 GB/day
5 years     = 50 GB * 365 * 5          = ~91 TB
Replicated  = 91 TB * 3                = ~274 TB

Conclusion — and this is the answer, not the arithmetic:

Neither number is hard. 12,000 reads/sec exceeds a single relational database (~1,000 QPS) but sits comfortably inside a key-value store (~10,000) and trivially inside a cache (100K–1M). 274 TB replicated is about 17 of our 16 TB reference machines. So capacity is not the interesting problem here — the interesting problems are unique ID generation without collisions and cache hit rate on a heavily skewed access distribution. I'd say that out loud and move the conversation there.

Drill B: Video streaming egress

A streaming service has 1 million concurrent viewers at an average bitrate of 5 Mbps. Estimate egress and decide what it means.

Egress = 1M * 5 Mbps = 5 * 10^12 bits/sec = 5 Tbps

Instances needed (25 Gbps NIC each) = 5 Tbps / 25 Gbps = 200 instances
                                       just to carry the bits

Conclusion:

5 Tbps is roughly 12x the total bandwidth of the Twitter-scale service from Lesson 9, and it would take 200 instances purely to move the bytes — before any of them does useful work. Serving this from origin is not viable at any reasonable cost.

So the CDN is not an optimization here, it is the architecture. Origin serves the manifest and the control plane; every video segment comes from an edge node. The design question becomes cache hit ratio at the edge and how to handle the long tail of unpopular content, since a miss is what actually reaches origin.

Drill C: Log ingestion

10,000 servers each emit 100 log lines per second at 200 bytes per line. Size the logging pipeline.

Lines/sec   = 10,000 * 100            = 1M lines/sec
Bytes/sec   = 1M * 200 B              = 200 MB/sec
Bandwidth   = 200 MB/sec * 8          = 1.6 Gbps
Per day     = 200 MB * 86,400         = ~17 TB/day
Per year    = 17 TB * 365             = ~6.3 PB/year

Conclusion:

1.6 Gbps of ingest is manageable, but 17 TB per day is the number that matters, and it makes retention the dominant cost decision — 7 days is 121 TB, a full year is 6.3 PB. Text logs typically compress around 10:1, which takes it to roughly 1.7 TB/day and changes the economics completely.

So the two levers are compression and retention tiers: keep recent logs hot and searchable, compress and tier older ones to object storage, and drop or sample the highest-volume, lowest-value lines. I'd also question whether 100 lines/sec/server is necessary — halving log verbosity is often the cheapest win available.

Drill D: Cache sizing

A service has 1 TB of total data. How much cache do you need, and what changes if the dataset is 100 TB?

Hot fraction (80/20 rule) = 20%

At 1 TB:    hot set = 200 GB   -> fits in one 256 GB reference server
At 100 TB:  hot set = 20 TB    -> ~80 machines of RAM

Conclusion:

At 1 TB the entire hot set fits in a single machine's memory, so caching is nearly free — one or two nodes for redundancy and you absorb most reads. At 100 TB the hot set alone needs roughly 80 machines' worth of RAM, which is a substantial distributed cache tier with its own partitioning, invalidation, and failure modes.

That is a phase change, not a scaling curve. The same technique is trivial at one size and a major subsystem at another, and knowing where the boundary sits is what tells you when to reach for it.

Rapid-fire probes

1. An interviewer says MySQL handles 2,000 QPS on average, not 1,000. Respond. · L5

2,000 is the same order of magnitude as 1,000, so it doesn't change any conclusion I've drawn. If a specific workload needs more precision I'd use a range — roughly 250 for complex queries, 1,750 for simple ones, 1,000 on average. The estimate exists to pick an architecture, and being off by 2x rarely changes that; being off by 100x always does.

2. Why does a key-value store serve ~10x the QPS of a relational database? · L4

Its API is much simpler. A key-value store does put and get — hash the key, fetch the value. A relational database has to parse, plan, and optimize a query before executing it. In-memory caches are simpler still, just reads and writes with no disk, which is why they reach 100K to 1M — and a read-dominated cache goes higher.

3. What's the hidden assumption in dividing daily requests by 86,400? · L5

That requests are uniformly distributed across every second of the day, which no real service experiences. It gives a lower bound, not a capacity plan. Real traffic peaks, so I'd apply a peak factor — 80/20 as a default, more for event-driven workloads.

4. Your estimate says 2 servers for 500 million DAU. What do you do? · L5

Stop and say it's wrong before the interviewer does. The arithmetic is fine; an assumption is broken — here it's uniform traffic distribution. I'd redo it with a realistic peak. Running a plausibility check on every result is the habit; a number that fails the smell test is a signal, not an answer.

5. A service shifts from CPU-bound to IO-bound. How does your planning change? · Staff

Per-request cost jumps by up to two orders of magnitude — from ~3 microseconds to ~200 or worse — so per-server RPS collapses and any server count derived from CPU-bound assumptions becomes badly optimistic. But the response isn't more servers: I'd buy faster storage and more IOPS, raise concurrency well above core count since threads are blocked rather than busy, and above all cut the IO itself with caching, batching, and fewer round trips. The tell is low CPU utilization alongside high latency.

6. You forgot something when converting storage to bandwidth. What? · L4

The factor of 8. Storage is quoted in bytes, network bandwidth in bits. Skipping the conversion is an 8x error and it's one of the most common mistakes in a live estimate.

7. Is 93 PB per year plausible for a Twitter-scale service? · L5

Yes. At 20 TB per disk that's about 5,000 disks, or 15,000 with three-way replication. At roughly 400 USD retail that's around 6 million USD of hardware — and organizations get significant volume discounts at that quantity. For a service with 500 million daily users, entirely reasonable.

8. Is ~400 Gbps of bandwidth unrealistically high? · L5

No. Data centers are commonly interconnected at 1 Tbps, and an organization at that scale runs multiple geographically dispersed data centers whose collective capacity easily exceeds 400 Gbps. Bandwidth toward the public internet is the more expensive part, which is exactly what a CDN is for.

9. A flash crowd arrives and all your DAUs show up at once. You can't provision for it. What do you do? · Staff

Degrade rather than scale. Drop per-user personalization first — during a major event everyone wants the same content anyway, and personalization is precisely what makes a page uncacheable. Shift to a static-like site pushed to CDN edge nodes and updated as new content arrives, so requests terminate near users and origin load collapses. Reduce multimedia so clients on congested networks get the information in fewer bytes. You can't buy 157,000 servers for an event you didn't see coming, but you can turn one page into something a CDN serves a billion times.

10. Your estimate depends on an assumption you're unsure about. How do you handle it? · Staff

Test its sensitivity out loud: if this is 2x off, does my conclusion change? If not, I state the assumption and proceed — precision I can't justify isn't worth the time. If it does change the conclusion, that assumption is load-bearing and I'd flag it as the first thing to measure. That framing turns an uncertain input into a known risk rather than a hidden one.

11. Compute says 15 servers, connections say 50. Which number do you use? · Staff

50, and more importantly I'd say why: connections bind first, so this is a connection-management problem and adding CPU buys nothing. The whole point of running all four estimates — compute, connections, storage, bandwidth — is to find which resource binds, because that's the one that dictates the architecture.

12. Why is a disk seek (4 ms) slower than sequentially reading 1 MB from disk (2 ms)? · Staff

Because on spinning media, finding the data costs more than reading it — the seek is mechanical, the read is streaming. That single fact is why sequential access patterns, batching, and log-structured storage designs matter so much: they amortize the expensive part across as much useful data as possible.

Self-check

The cheat sheet next compresses every number in this chapter onto one page.