Numbers & Units You Must Know Cold
Round to powers of 10 — never 1024
In a real design discussion you never use 1024. The unit ladder is just “add three zeros”:
| Unit | ≈ bytes | Think |
|---|---|---|
| 1 KB | 10³ | a thousand |
| 1 MB | 10⁶ | a million |
| 1 GB | 10⁹ | a billion |
| 1 TB | 10¹² | a trillion |
| 1 PB | 10¹⁵ | a quadrillion |
“Bytes per thing” — memorize ~8 anchors
You can’t size storage without knowing how big one record is. Memorize these and interpolate the rest:
| Thing | Size |
|---|---|
| char (ASCII) / bool | 1 byte |
| int (int32) | 4 bytes |
| pointer / reference | 8 bytes |
| int64 / timestamp · UUID | 8 bytes · 16 bytes |
| a short text post (~280 chars) | ~300 bytes |
| one DB metadata row | ~1 KB |
| a web page (HTML) | ~100 KB |
| a compressed photo | ~1 MB |
| 1 min of audio (mp3) | ~1 MB |
| 1 min of HD video | ~10–50 MB |
The time trick that unlocks “per second”
Seconds in a day ≈ 86,400 ≈ 10⁵. Memorize this one number.
- 1 request/sec ≈ 100K/day ≈ 2.5M/month ≈ 30M/year.
- Going back: 1 million events/day ÷ 10⁵ ≈ ~10/sec.
- 1 month ≈ 2.5 × 10⁶ s · 1 year ≈ 3 × 10⁷ s.
Latency numbers (order of magnitude)
| Operation | Time |
|---|---|
| L1 cache reference | ~1 ns |
| Main memory (RAM) | ~100 ns |
| SSD random read (4 KB) | ~100 µs |
| Round trip, same datacenter | ~0.5 ms |
| Read 1 MB sequentially from SSD | ~2 ms |
| Disk seek (HDD) | ~10 ms |
| Round trip, cross-continent | ~150 ms |
Takeaway: RAM is ~1,000× faster than SSD and ~100,000× faster than a disk seek; a cross-continent round trip dwarfs everything — minimize them.
Throughput anchors (for server-count math)
| Resource | Rough anchor |
|---|---|
| One app server | ~1K–10K simple QPS |
| Redis / in-memory store | ~100K ops/s |
| Postgres/MySQL (simple reads) | ~a few K – 50K QPS |
| SSD | ~500 MB/s sequential |
| 1 Gbps NIC | = 125 MB/s |
| Kafka (per partition) | ~MBs/s |
Availability — the “nines”
| Availability | Downtime / year |
|---|---|
| 99% (“two nines”) | ~3.65 days |
| 99.9% | ~8.8 hours |
| 99.99% | ~52 minutes |
| 99.999% (“five nines”) | ~5 minutes |
These anchors are exactly what the Capacity Estimation playbooks plug into. Memorize the bold ones first. For the end-to-end capacity chain and the laws that govern sizing, see the Systems Cheat-Sheet.
One-number drill: from daily usage to QPS and storage
The interview gives you one number — usually DAU or monthly active users. Everything else follows. Practice until you can do this in under 60 seconds.
Worked example: photo sharing
Given: 10M daily active users (DAU), each posts 3 photos on average.
- Daily actions:
10M × 3 = 30M photos/day. - Average QPS:
30M / 86,400 s ≈ 347 writes/sec. - Peak QPS: assume 20% of daily volume lands in 4 hours:
30M × 0.20 / (4 × 3600) ≈ 417 writes/sec. For a headroom multiplier of 3× average, peak ≈347 × 3 ≈ 1,000 writes/sec. Both are the same rule — peak = average × (traffic share ÷ time share): “20% in 4 hours” is a concentration of0.20 ÷ (4/24) = 1.2×(a mild, flat day), while “3× average” assumes most traffic packed into a ~8-hour window. State which day-shape you are assuming; for a consumer app the derived diurnal answer is usually 2–3× — see Deriving the Peak Factor. - Daily storage: at 2 MB/photo,
30M × 2 MB = 60 TB/day. - 5-year storage:
60 TB × 365 × 5 ≈ 110 PBraw (logical data, pre-replication). With 3× replication that is ~330 PB provisioned on disk. Compression applies to the raw bytes before replication multiplies them: 2:1 compression gives ~55 PB raw → ~165 PB provisioned.
Try it yourself: messaging
Given: 50M DAU, each sends 50 messages/day. Messages are ~200 bytes each. What are the average write QPS, peak write QPS (20% in 4 hours), daily storage, and 1-year storage?
Show answer
- Daily messages:
50M × 50 = 2.5B/day. - Average QPS:
2.5B / 86,400 ≈ 28,935 writes/sec. - Peak QPS:
2.5B × 0.20 / 14,400 ≈ 34,722 writes/sec; with 3× headroom, ~90k writes/sec. - Daily storage:
2.5B × 200 B = 500 GB/day. - 1-year storage:
500 GB × 365 ≈ 182 TBbefore replication/compression.
Latency budget composition: p99 per hop → total p99
A 100 ms end-to-end budget is eaten one hop at a time. The safe rule for a first-pass design is:
Serial hops add; parallel hops take the max.
Example request path and p99 budget per hop:
| Hop | p99 latency |
|---|---|
| DNS resolution | 5 ms |
| TCP + TLS handshake | 20 ms |
| Load balancer | 1 ms |
| Application logic | 50 ms |
| Cache read (Redis) | 2 ms |
| DB read (Postgres, indexed) | 10 ms |
If the cache misses and the app hits both Redis and Postgres serially, the budgeted p99 is 5 + 20 + 1 + 50 + 2 + 10 = 88 ms. In practice the true p99 of the sum is slightly less than the sum of p99s because percentiles do not add linearly, but summing them is the conservative design estimate that survives review.
If the app instead queries Redis and a search index in parallel, the budget is 5 + 20 + 1 + 50 + max(2, search_p99). Parallel calls do not add latency; they add tail-risk complexity.
Rule of thumb: keep your sum-of-p99s below 70% of the target so you have margin for retries, GC pauses, and the occasional slow replica.
Capacity anchors quick-reference card
Print this mentally. Every sizing conversation starts here.
| Anchor | Value | Use it for |
|---|---|---|
| Seconds per day | 86,400 ≈ 10⁵ | DAU → average QPS |
| Seconds per month | 2.5M ≈ 2.5 × 10⁶ | Monthly events → QPS |
| Seconds per year | 31.5M ≈ 3 × 10⁷ | Yearly volume → QPS |
| 1 req/s | ~100K/day | Reverse: QPS → daily capacity |
| 1 GB/s | ~86 TB/day | Streaming throughput → daily storage |
| 1 app server | ~1K–10K simple QPS | Server count |
| 1 Redis | ~100K ops/s | Hot cache / counter sizing |
| 1 Postgres | ~a few K – 50K QPS | DB sizing and replica count |
| 1 Gbps NIC | 125 MB/s | Network vs storage math |
| SSD sequential read | ~500 MB/s | Disk scan time |
| Cross-continent RTT | ~150 ms | Geo-replication latency |
One-card trick: pick the two numbers that dominate your problem — usually DAU × actions/day and bytes per action — and run them through the anchors above. The rest is arithmetic, not magic.
Unit traps that sink estimates
Most estimation errors are not arithmetic mistakes — they are unit mistakes. Three that reliably blow up a design review:
- Bits vs bytes (the 8× trap). Network links are quoted in bits; storage in bytes. A live-video fan-out of
5 Mbps × 200,000 viewers = 1,000,000 Mbps = 1 Tbps— divide by 8 to get 125 GB/s of egress. Skip the ÷8 and you mis-provision by 8×. Likewise a 40 Gbps NIC is only40 / 8 = 5 GB/s. - Raw vs replicated storage. You size on the logical data but pay for replicas:
1B rows × 1 KB = 1 TBlogical becomes 3 TB on disk at replication factor 3. Always say whether a storage number is pre- or post-replication (and pre- or post-compression). - /day vs /second. "1 million events/day" is only
1e6 / 86,400 ≈ 12/son average — but peak is often 10–20× that. State the axis (per-day vs per-second) and the peak multiplier explicitly, or the reviewer assumes the worse one.
Formulas are standard/public-domain engineering math. Approach and reference-table format adapted from the System Design Primer (CC BY 4.0), Jeff Dean’s latency numbers, the DesignGurus capacity-estimation guide, and Little’s Law.
🤖 Don't fully get this? Learn it with Claude
Stuck on Numbers & Units You Must Know Cold? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **Numbers & Units You Must Know Cold** (System Design) and want to truly understand it. Explain Numbers & Units You Must Know Cold from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Socratic — adapts to where you're stuck.
Teach me **Numbers & Units You Must Know Cold** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Active recall exposes what you missed.
Quiz me on **Numbers & Units You Must Know Cold** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Intuition + hook + flashcards for long-term memory.
Help me remember **Numbers & Units You Must Know Cold** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.