An interviewer asks you to design a URL shortener. Should it use one database or a hundred? Do you need a cache? Can images live on the same server?
You cannot answer any of these without numbers. A design for a thousand users and a design for a billion share almost nothing, and picking components before knowing which you are building is guesswork.
Estimation is the step that converts a vague prompt into constraints you can design against. It takes five minutes and it justifies every decision that follows.
What is actually being tested
Nobody expects accuracy. Interviewers are checking three things:
Can you reason with orders of magnitude? Is this thousands or billions? The difference between 10⁶ and 10⁹ changes the architecture; the difference between 1.2M and 1.8M changes nothing.
Do you state your assumptions? "I'll assume 100 million daily users and a 100:1 read ratio" is the correct move. Silent assumptions are unverifiable.
Do you interpret the result? This is the part candidates skip and the part that earns marks. A number alone is arithmetic. "That's 50 TB a day, so a single machine is out and we need to shard" is engineering.
Numbers worth memorising
A small set of facts covers almost every estimate.
Time
- 86,400 seconds in a day — round to 100,000 for mental maths. It makes every division trivial and the 15% error is irrelevant.
- 2.5 million seconds in a month.
Size
| Item | Size |
|---|---|
| Character (ASCII) | 1 byte |
| UUID | 16 bytes |
| Timestamp | 8 bytes |
| Typical database row | 100 bytes – 1 KB |
| Small image (thumbnail) | 50 KB |
| Photo | 1–3 MB |
| Minute of video | ~50 MB |
Latency — the ones from the fundamentals lesson
| Operation | Time |
|---|---|
| Memory read | 100 ns |
| SSD read | 100 µs |
| Disk seek | 10 ms |
| Round trip, same datacentre | 500 µs |
| Round trip, cross-continent | 150 ms |
Capacity of one commodity server
- 1,000–10,000 requests/second, depending on work per request
- A few hundred database connections
- Tens of thousands of concurrent open connections
The method
Every estimate walks the same four steps, and each one feeds the next.
Diagram, as text
- Users and actions leads to Requests per second
- Requests per second leads to Storage
- Requests per second leads to Bandwidth
- Storage leads to Does one machine fit?
- Bandwidth leads to Does one machine fit?
- Does one machine fit? leads to Shard, cache, or move to object storage (no)
- Does one machine fit? leads to Keep it simple (yes)
Always in this order. Each step feeds the next.
1. Users and actions
Start from daily active users and how often each does the thing.
100M DAU, each posting once a week and reading 50 posts a day.
2. Requests per second
Convert daily totals to a rate, then apply a peak multiplier.
Writes: 100M ÷ 7 ≈ 14M/day ÷ 10⁵ ≈ 140/s Reads: 100M × 50 = 5B/day ÷ 10⁵ ≈ 50,000/s Peak at 3x: ~150,000 reads/s
Peak matters. Traffic is never flat — it follows waking hours and events. Design for peak, not average, and 2–3x average is a defensible assumption to state.
3. Storage
Multiply objects by size, then extend to a year.
14M posts/day × 1 KB = 14 GB/day ≈ 5 TB/year (text only) With one 2 MB image on 10% of posts: 1.4M × 2 MB = 2.8 TB/day ≈ 1 PB/year
Notice how media dominates. This is why every case study separates metadata from blob storage.
4. Bandwidth
Throughput out of the system.
150,000 reads/s × 200 KB average response = 30 GB/s egress
A number like that immediately tells you a CDN is not optional.
Turning numbers into decisions
The whole point. Each result should trigger a specific conclusion.
| Finding | What it means |
|---|---|
| Reads ≫ writes (10:1 or more) | Cache aggressively; add read replicas |
| Writes are high (>10,000/s) | One leader will not cope — shard |
| Storage exceeds a few TB | Cannot fit one machine; shard or use object storage |
| Egress in GB/s | CDN required |
| Requests/s under ~1,000 | One server is genuinely enough |
| Data is small (under 100 GB) | Keep it simple; it may fit in memory |
That last pair matters as much as the others. Estimation protects you from over-engineering as well as under-engineering, and an interviewer notices when you say "this fits comfortably on one database, so I'll start there".
A worked example
Design a URL shortener. 100M new URLs per day, read 100x more than written.
Rate
Writes: 100M ÷ 10⁵ = 1,000/s Reads: 1,000 × 100 = 100,000/s, peak ~300,000/s
Storage
Per record: short code (7B) + long URL (~100B) + metadata (~20B) ≈ 130B, round to 200 B 100M × 200 B = 20 GB/day ≈ 7 TB/year
Key space
Base62 with 7 characters = 62⁷ ≈ 3.5 trillion — ample for 36 billion URLs a year
Cache
If 20% of URLs produce 80% of traffic, caching one day of hot URLs is 20M × 200 B = 4 GB — trivially fits in memory
Now interpret, which is the part that counts:
"Reads outnumber writes 100:1, so this is a caching problem — 4GB of hot URLs in Redis absorbs most of the 300,000 peak reads. 1,000 writes/s is comfortable for a single database leader, so I don't need to shard writes initially. But 7TB a year means I will need to shard on storage within a couple of years, so I'll pick a shard key now. And every read is a primary-key lookup with no joins, which suits a key-value store."
Four sentences, and they justify the entire architecture.
Check your understanding
Common mistakes
Skipping estimation and designing anyway. Every later choice is then unjustified.
Not applying a peak multiplier. Designing for the average means falling over daily at the busy hour.
Forgetting replication in storage figures. Three replicas means three times the disk. It is easy to under-provision by a factor of three.
Producing a number and not interpreting it. "50 TB per day" earns nothing on its own.
Estimating things that do not affect the design. If the answer will not change a component choice, skip it.
Being afraid to ask. "How many daily active users should I assume?" is a good question, not a weakness.
Practice
Size a photo-sharing service: 200 million daily active users, 10% of whom upload one 3 MB photo a day, and every user views 40 photos a day. Give writes per second, reads per second, daily storage, and read bandwidth — then say what each number rules out.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Take a day as 10⁵ seconds and round hard. You are choosing an architecture, not filing accounts.
Show a strong answer
Rate
- Uploads: 200M × 10% = 20M a day ÷ 10⁵ = 200 writes/s, peak ~600/s
- Views: 200M × 40 = 8B a day ÷ 10⁵ = 80,000 reads/s, peak ~240,000/s
Storage
- 20M × 3 MB = 60 TB a day ≈ 22 PB a year before replication; ~66 PB at three copies
Bandwidth
- Read: 80,000/s × 3 MB = 240 GB/s. This is the number that should stop you.
What each one rules out
- 200 writes/s is unremarkable — a single database leader handles the metadata comfortably, so do not shard writes on day one.
- 400:1 read-to-write says this is a caching and distribution problem, not a write-throughput problem.
- 60 TB a day rules out storing photo bytes in the database at all. Blobs go to object storage; the database keeps rows of a few hundred bytes.
- 240 GB/s of egress is not something you serve from origin. A CDN is not an optimisation here, it is the architecture — and it also collapses the read number your servers ever see.
Note how the largest number changed the design and the smallest one prevented unnecessary work.
A colleague reports '1,357.4 requests per second', from 15,847,392 users × 7.4 actions ÷ 86,400. Every figure is arithmetically correct. Name three things still wrong with the answer.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Ask what would change in the design if the answer were 1,100, or 1,600.
Show a strong answer
The arithmetic checks out. What is wrong is everything around it.
- The precision is invented. "7.4 actions" is itself a guess carried to two significant figures, and 15,847,392 will be a different number tomorrow. Multiplying an estimate by an estimate does not produce a measurement. Reporting the result to one decimal place claims knowledge nobody has.
- It cannot be checked aloud. Rounded, it is 16M × 7 ÷ 10⁵ ≈ 1,100/s — close enough, and a listener can follow every step and challenge an assumption. The precise version can only be verified with a calculator, so in practice nobody verifies it, and a wrong assumption sails through.
- It stops before the useful sentence. 1,357/s and 1,100/s lead to exactly the same architecture. What earns marks is the next line: "about a thousand writes a second is comfortable for a single database leader, so I will not shard writes yet — but I will pick a shard key now, because storage will force it before throughput does."
A good estimate is one significant figure and one conclusion. The figure is the cheap part.
Key takeaways
- Estimation converts a vague prompt into constraints, and it justifies every component you choose afterwards.
- Round 86,400 to 100,000 and work in powers of ten — accuracy is not the point.
- Follow the order: users → requests per second → storage → bandwidth, and apply a 2–3x peak multiplier.
- State assumptions out loud; silent ones cannot be checked or corrected.
- Always interpret the result. "50,000 reads/s at a 100:1 ratio means caching is the core of this design" is the sentence that earns marks.
- Estimation prevents over-engineering too — discovering it fits on one server is a valid and valuable outcome.
Further reading
- Jeff Dean, "Numbers Everyone Should Know" (Stanford lecture notes, 2007) — the origin of the latency table this lesson compresses.
- Peter Norvig, "Teach Yourself Programming in Ten Years" — the appendix that popularised the same latency figures.
- Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung, "The Google File System" (SOSP 2003) — a worked example of storage estimates driving an architecture.
- Douglas Hubbard, How to Measure Anything (Wiley, 2014) — estimating under uncertainty, and why ranges beat single figures.
- Sanjeev Sharma, "Back-of-the-Envelope Calculations" in Programming Pearls by Jon Bentley (Addison-Wesley, 1986), column 7 — the classic treatment of order-of-magnitude reasoning.