Cruxly › System design › Running the Design Interview
Estimating the Load
get to one number that constrains everything else
Open the interactive lessonTurn the scope into figures: requests per second, bytes stored per year, bandwidth at peak. You are not trying to be accurate. You are trying to find out which order of magnitude you are in, because that is what decides whether this runs on one box or two hundred.
You are estimating to make one decision
Estimation is not a ritual. It exists to answer questions like:
- Does the working set fit in memory on one machine, or do I need a distributed cache?
- Is a single primary database enough for the write rate, or must I partition?
- Is bandwidth the constraint rather than compute? (For anything with media, usually yes.)
- Each of those is a factor-of-a-thousand question, which is why sloppy arithmetic is fine and skipping the arithmetic is not.
- Being wrong by 3× changes nothing. Being wrong about whether it is gigabytes or petabytes changes everything.
- Announce the decision the number is for: "I want to know if the hot set fits in RAM" — then compute exactly that.
- It stops you producing five numbers you never use, which is the other common failure.
Numbers worth memorising
Round aggressively. These are the only ones you need.
| Quantity | Use |
|---|---|
| 100,000 seconds ≈ 1 day | daily ÷ 100k = average per second |
| 3 × 10⁷ seconds ≈ 1 year | storage per year |
| 1 million ≈ 10⁶, 1 billion ≈ 10⁹ | keep exponents, not digits |
| Peak ≈ 2–3× average | always state the multiple you used |
| 1 KB — a text record with metadata | rows, messages, events |
| 1 MB — a photo; ~40–100 MB/min — 1080p video | anything with media dominates storage |
| ~100 ns — memory reference; ~100 µs — NVMe random read | why an in-memory cache beats disk |
| ~0.5 ms — round trip within a datacentre; ~100 ms — cross-continent | why you cache, and why you place data near users |
| ~1–10k req/s — one app server; ~100k+ ops/s — one Redis node | how many boxes a tier needs |
| ~10–20k small durable writes/s — one OLTP primary | the "do I need to shard?" line |
Don't confuse that last number with bulk-load speed. A single node can ingest on the order of a million rows per second with COPY or big batched inserts, but that isn't transactional traffic — each user-facing write is its own durable commit, and that's what caps a primary in the tens of thousands per second (more with careful batching and fast disks).
- The last one is the workhorse. If your write rate is 5,000/s you do not need to shard and you should say so.
- Candidates who shard a system that fits on one box are demonstrating pattern-matching, not judgement.
A worked estimate
50 million daily active users, each sending 40 messages a day, each message 1 KB.
@@ 1 | Writes 50M × 40 = 2 × 10⁹ messages/day. Divide by 10⁵ seconds ≈ 20,000 writes/second average, so ~50,000 at peak.
@@ 2 | Reads A chat is read more than written — assume 3 reads per message: 60,000 reads/second average.
@@ 3 | Storage 2 × 10⁹ × 1 KB = 2 TB/day, about 700 TB/year of raw data — and about 2 PB/year stored once you multiply by a replication factor of 3, which is the number the storage bill actually sees. That is a partitioned store with a retention policy, not one Postgres box.
@@ 4 | Hot set People almost only read recent messages. Last 24 hours is 2 TB — too much for one cache node, fine for a modest cluster. Last hour is ~80 GB, which fits comfortably.
:::key What this tells me — this is the entire point
- 50k writes/s exceeds a single primary, so writes partition by conversation.
- 700 TB/year raw (~2 PB with 3× replication) makes cold storage tiering a requirement, not a nice-to-have.
- A 3:1 read:write ratio is still read-dominated, but it's not read-skewed enough for replicas to be the main lever — every replica would still apply all 50k writes/s. Writes are the scaling constraint, so I partition first rather than reaching for read replicas.
:::
Say the ratio, not just the totals
- Totals tell you how big. Ratios tell you what kind of system it is — and they are what senior candidates lead with.
| Ratio | System | What it dictates |
|---|---|---|
| 1000:1 read:write | A content site | Cache aggressively, denormalise freely, replicate reads. The write path can be slow |
| ~1:1 to a few:1 read:write | Messaging, logging | Caching and replicas buy little — the write path is the system |
| Write-heavy, rare reads | Telemetry | Append-only storage, batch compaction; reads are allowed to be slow |
| 1:10,000,000 fan-out | A celebrity posting to 10M followers | That single number is the whole design problem for a social feed |
:::key One ratio beats eight totals If you produce one ratio and design around it, you have done more than a candidate who produced eight totals and drew no conclusion from any of them. :::
Doing the arithmetic without embarrassing yourself
Work in exponents, not digits.
50 million × 40 = ... "two thousand million"?
(counting zeros under pressure — this is where people slip)5×10⁷ × 4×10¹ = 20×10⁸ = 2×10⁹
(mantissas multiply, exponents add — no zeros to drop)- Round to one significant figure the moment you can. 86,400 seconds is 10⁵. 365 days is 400.
- Say "call it" out loud when you round, so the interviewer knows it's deliberate rather than sloppy: "call it 100,000 seconds in a day."
- Write every number down. You will need them in the deep dive, and re-deriving them under pressure is exactly where mistakes happen.
:::key On getting it wrong
- Catch your own arithmetic error, fix it out loud, move on — that reads as rigour.
- If the interviewer catches it, thank them and fix it.
- Neither is fatal. Refusing to estimate at all is.
:::
How to say it in the interview
"Let me get rough numbers before I draw anything — I want to know whether this is a single-database problem or a sharding problem, and that's a factor-of-a-thousand question."
Checklist
- Named the decision each number is for, before computing it
- Computed writes/s, reads/s and storage/year
- Stated the peak multiplier used
- Derived the read:write ratio and said what kind of system it makes this
- Worked in powers of ten and rounded out loud
- Turned each number into a design consequence
- Left the numbers written down for the deep dive