Core Concepts
Numbers to Know
The handful of latency, throughput and capacity figures that let you size a system in your head — and a worked back-of-the-envelope estimate you can copy.
You can't reason about a design without a feel for the numbers. You don't need precision — you need the right order of magnitude, instantly, so you can answer "does this fit on one machine?" or "how many servers is that?" without a spreadsheet. This lesson is the small set of figures worth memorising, plus how to use them.
Latency: how long things take
Rounded to powers of ten — that's all the resolution you need:
| Operation | Rough time |
|---|---|
| L1 cache / branch | ~1 ns |
| Memory read | ~100 ns |
| Read 1 MB from memory | ~10 µs |
| SSD random read | ~100 µs |
| Round trip inside a data centre | ~500 µs |
| Read 1 MB over the network (same DC) | ~1 ms |
| SSD read 1 MB | ~1 ms |
| Disk (HDD) seek | ~10 ms |
| Round trip across a continent | ~50–70 ms |
| Round trip around the world | ~150 ms |
The relationships matter more than the exact values: memory is ~100× faster than SSD; a same-DC network hop is ~1000× slower than memory; a cross-continent round trip is another ~100× on top. This is why we cache, co-locate, and avoid chatty cross-service calls.
Capacity: what fits
| Thing | Rough figure |
|---|---|
| Seconds in a day | ~86,400 (≈ 10^5) |
| Seconds in a month | ~2.5 million (≈ 2.5 × 10^6) |
| 1 KB | a short text record / small JSON |
| 1 MB | a photo, a long document |
| A single modern DB server | comfortably holds hundreds of GB to a few TB |
| One server's connections | thousands concurrent |
The "seconds in a day" figure is the one you'll use most — it converts "daily volume" into "per second" in your head.
Throughput rules of thumb
Exact numbers depend on everything, but these order-of-magnitude anchors are enough to size a system:
- A single app server: thousands of simple requests/second.
- A cache (Redis): ~100k+ ops/second.
- A relational DB: thousands of writes/second, more reads — and far more with replicas and caching in front.
If your estimate lands in the hundreds-of-thousands-per-second range, you're in "needs a cache and probably a queue" territory. If it's in the millions, you're designing a genuinely large system.
Worked example
Design a URL shortener. Assume 100M new links/month and a 100:1 read:write ratio.
Writes per second:
100M / 2.5M seconds ≈ 40 writes/sec. Tiny — one database handles this without breaking a sweat.
Reads per second:
40 × 100 = 4,000 reads/sec. Still modest, but reads dominate — a perfect fit for a cache in front of the database.
Storage over 5 years:
100M/month × 60 months = 6B links. At ~500 bytes each, that's ~3 TB. One beefy database (or light sharding) holds it; nothing exotic needed.
The point of the exercise isn't the exact figures — it's that two minutes of arithmetic told us the write path is trivial, the read path wants a cache, and the data fits on one or two machines. That immediately shapes the whole design and keeps you from over-engineering.
How to use these in an interview
- Convert the requirement to per-second using seconds-in-a-day/month.
- Separate reads from writes — they almost always need different treatment.
- Multiply out storage over a realistic horizon to settle "one machine or many?"
- State your assumptions ("assume 100M/month, 100:1 reads") so the interviewer can correct the premise, not the math.
Estimating out loud — even roughly — is one of the clearest signals that you can reason about scale rather than guess at it.
That's Core Concepts. From here, the Question Breakdowns, Patterns, Key Technologies and Advanced Topics sections build on exactly these ideas.