Estimation & requirements · How it works
8 min read- How it works
- The opening funnel
- Functional requirements: pick the core, park the rest
- Non-functional requirements: the ones that change the design
- Numbers every estimate leans on
- Estimating QPS
- Estimating storage
- Estimating bandwidth and memory
- From numbers to constraints
- Running the first five minutes
- Common estimation mistakes
How it works
The opening funnel
Each step narrows the space. Skipping straight from the prompt to boxes and arrows is the most common reason a candidate designs the wrong system well.
Functional requirements: pick the core, park the rest
Ask who the users are and what the three to five things are that they must be able to do. For a URL shortener: create a short link, redirect a short link, optionally set an expiry, optionally see click counts. Say explicitly what is out of scope (user accounts, custom domains, spam detection) so the interviewer can pull it back in if they want it. Writing the list down gives you an API surface to sketch later.
A: Because scope is the interviewer's lever, not yours. Naming what you are leaving out (accounts, analytics, abuse detection) shows you saw it, keeps the design small enough to finish in the time, and gives the interviewer a clean moment to say "actually, I want analytics" before you have drawn a design that cannot support it. Silently ignoring a feature reads as not having thought of it; silently including everything leaves no time for depth.
Non-functional requirements: the ones that change the design
Only list the non-functional requirements that would change your architecture:
- Latency — p99 target for the hot path (a redirect in under 50 ms is a cache-first design).
- Availability — 99.9% allows about 43 minutes of downtime a month; 99.99% allows about 4. Each extra nine usually means another region or another redundant tier.
- Durability — can we lose a write? Payments: never. View counters: a few is fine.
- Consistency — must a reader see a write immediately, or is a few seconds of staleness acceptable?
- Scale shape — read-heavy or write-heavy, bursty or smooth, global or regional.
A: A 30-day month has about 43,200 minutes. 99% allows about 7.2 hours, 99.9% about 43 minutes, 99.99% about 4.3 minutes, and 99.999% about 26 seconds. The jump from three to four nines is the point where a human cannot respond in time, so recovery must be automatic; from four to five usually means active-active across regions.
Numbers every estimate leans on
| Quantity | Round value |
|---|---|
| Seconds in a day | ~86,400, round to 100,000 (10^5) |
| Seconds in a month | ~2.6 million, round to 2.5 × 10^6 |
| Requests per day → per second | divide by 10^5 |
| 1 KB × 1 million | 1 GB |
| 1 KB × 1 billion | 1 TB |
| Main memory reference | ~100 ns |
| SSD random read | ~100 µs |
| Round trip inside a data centre | ~0.5 ms |
| Round trip across a continent | ~50–100 ms |
| One commodity server | ~10k–50k simple HTTP requests/s, ~64–256 GB RAM |
| One relational primary | ~5k–20k simple writes/s before it hurts |
The latency numbers matter for the ratio between them, not their exact value: memory is roughly 1,000 times faster than SSD, and a cross-region hop costs as much as hundreds of local ones.
A: Divide by 100,000. A day has 86,400 seconds, so rounding to 10^5 overestimates QPS by about 15%, which is a safe direction to be wrong in. Ten million requests a day is therefore about 100 per second on average. Then apply a peak factor, typically 2 to 10, because traffic is never uniform across the day.
Estimating QPS
- Start from users: daily active users (DAU) × actions per user per day = requests per day.
- Divide by 10^5 for average QPS.
- Multiply by a peak factor (2–3× for smooth global traffic, 5–10× for a launch, a sale or a sports event).
- Split into reads and writes using the ratio from the requirements.
Example: 100 M DAU, each creating 0.1 links and following 10 per day. Writes: 10 M/day ≈ 100/s average, ~300/s peak. Reads: 1 B/day ≈ 10,000/s average, ~30,000/s peak. The conclusion: writes are trivial, reads need a cache or CDN in front.
A: The ratio between the busiest period and the daily average. Traffic follows time zones, working hours and events, so the average understates what the system must survive. A system sized for the average falls over every evening. Multiply the average by 2–3 for steady consumer traffic and more for spiky workloads (flash sales, ticket launches, live events), and size capacity for the peak plus headroom.
Estimating storage
Storage = objects per day × size per object × retention × replication factor.
- Pick a size per record by listing its fields: a short link is roughly 7-byte key + 100-byte URL + timestamps and metadata ≈ 500 bytes with overhead.
- 10 M links/day × 500 B = 5 GB/day ≈ 1.8 TB/year; × 5 years ≈ 9 TB; × 3 replicas ≈ 27 TB.
- Indexes add 20–50% on top of row data; media dwarfs everything else and belongs in object storage, not the database.
The answer's shape matters more than the number: 27 TB of small rows means the table outgrows one comfortable node and will need partitioning within a few years.
A: Because the disk you buy is the disk every copy uses. A durable database keeps two or three replicas, object stores keep three copies or erasure-coded equivalents, and backups add more. An estimate of 9 TB of logical data is really 27 TB of provisioned disk at replication factor three, and that difference can move a design from one node to a sharded cluster.
Estimating bandwidth and memory
- Bandwidth = QPS × bytes per request/response. 30,000 redirects/s × 500 B ≈ 15 MB/s, trivial. 1,000 video starts/s × 5 Mbit/s = 5 Gbit/s egress, not trivial — that forces a CDN.
- Cache memory follows the 80/20 rule: if 20% of objects serve 80% of reads, cache that 20%. 20% of one day's 1 B reads touch maybe 100 M distinct links × 500 B = 50 GB, which fits in a small Redis cluster.
A: Estimate the hot working set, not the whole dataset. Take the distinct objects read in a window (often a day), apply the skew (commonly 20% of items take 80% of reads), and multiply by the object size plus cache overhead. If that fits in the RAM of a few nodes, a cache-aside layer is cheap and effective; if the hot set is itself terabytes, you need a CDN, a partitioned cache, or a different access pattern.
From numbers to constraints
Every estimate should end in a sentence of the form "this means…". If a number does not change a decision, you did not need to compute it.
A: To find out which design the numbers force, not to be accurate. Estimates separate "one Postgres and a cache" from "partitioned log plus sharded store" before you draw anything. An order-of-magnitude answer with stated assumptions is enough; spending five minutes on precise arithmetic that changes no decision is time taken from the deep dive.
Running the first five minutes
Say assumptions out loud and write them down. If the interviewer disagrees with a number, you change one line rather than argue.
A: Propose a number and ask for confirmation: "I'll assume 50 million daily users and a 100:1 read-to-write ratio — does that match what you're picturing?" It shows you know the number matters, keeps momentum, and gives the interviewer a cheap chance to redirect. Waiting for them to volunteer scale, or refusing to estimate without it, wastes the opening.
A: Because they scale with different tools. Reads scale out cheaply with replicas, caches and CDNs; writes need a single authoritative place per key and scale only by partitioning or batching. A system at 30,000 total QPS is easy if 29,900 are cacheable reads and hard if 20,000 are writes to the same table.
Common estimation mistakes
- Computing to four significant figures instead of one.
- Forgetting the peak factor and sizing for the average.
- Forgetting replication, indexes and retention in storage.
- Stopping at a number and never saying what it implies.
- Estimating things that do not matter for this design (the bandwidth of a URL shortener's write path).
- Letting estimation consume ten minutes; budget three to five.
A: Estimate what could change the architecture: peak write QPS (single primary or partitioned), peak read QPS and ratio (caching, replicas), total storage over the retention period (single node or sharded, database or object store), and egress bandwidth when media is involved (CDN). Skip what is obviously small for this problem — the write bandwidth of text records, server CPU for a simple CRUD path — and say that it is small rather than computing it.