Numbers Every Engineer Should Know

In one line

Design decisions are only as good as the numbers behind them. Memorize a small set of latency, throughput, and size figures so you can size any system in your head during an interview.

0/6 · 0%

Think of it like this

A chef who knows 'boiling pasta takes 10 minutes, the oven takes 20 to heat up'. With those numbers in their head, they can plan a whole dinner. Engineers do the same with 'memory takes 100 nanoseconds, a network call takes half a millisecond'.

Key ideas

01
Latency ladder: L1 cache ~1ns → RAM ~100ns → NVMe SSD random read ~20–100µs → same-DC round trip ~0.5ms → HDD seek ~5–10ms → cross-continent round trip ~70–150ms.
02
The gaps are what matter: memory is ~1,000× faster than SSD, and a same-DC network hop costs ~5,000× a RAM read. So every network call in a request path needs a reason.
03
Rough single-node throughput: Redis ~100k ops/s per core; tuned Postgres ~10–50k simple queries/s; one Kafka broker ~100s of MB/s; one app server ~1–10k req/s depending on the work per request.
04
Time conversions: 1 day ≈ 86,400s ≈ 10^5 s. So 1M requests/day ≈ 12 req/s and 100M/day ≈ 1,200 req/s. Peak is usually 2–3× average; use 10× for spiky consumer traffic.
05
Size conversions: 1 KB × 1M = 1 GB; 1 KB × 1B = 1 TB; 1 MB × 1B = 1 PB. Plan for replication (×3) and headroom (×1.3–2) on top.
06
Typical object sizes: UUID 16B, tweet with metadata ~300B–1KB, row with ~10 columns ~200B–1KB, thumbnail ~10–50KB, photo ~200KB–2MB, 1 min of 1080p video ~50–100MB.
07
Bandwidth: 1 Gbps ≈ 125 MB/s; 10 Gbps ≈ 1.25 GB/s. Egress, not compute, is often the biggest line on a media platform's bill.
08
Human thresholds: <100ms feels instant, <1s keeps the user's flow, >10s loses them. Work backwards from these to set p99 budgets.
09
Interview rule: round aggressively (powers of 10), state your assumptions, and let each number drive a decision, e.g. '1.2k writes/s fits one primary, so we don't shard yet'.

Java / Spring map

→
JVM reality check: a GC pause of 50–200ms dwarfs your 1ms Redis call. Pick ZGC or G1 and measure p99, not the average.
→
HikariCP pool sizing: connections ≈ (core_count × 2) + effective_spindles is the starting point. A 200-connection pool usually makes a DB slower, not faster.

Code & diagrams

LatencyNumbers.mdmarkdown

Commit these to memory. Orders of magnitude matter, exact values do not.

Operation                                   Time         Relative
L1 cache reference                          1 ns
Branch mispredict                           3 ns
L2 cache reference                          4 ns
Mutex lock/unlock                           17 ns
Main memory reference                       100 ns       100× L1
Compress 1 KB (Snappy/LZ4)                  2 µs
Read 1 MB sequentially from RAM             3 µs
SSD random read (4 KB)                      16–100 µs
Round trip within same datacenter           500 µs       0.5 ms
Read 1 MB sequentially from SSD             50 µs–1 ms
Redis GET over the network (same AZ)        0.2–1 ms
Simple indexed SQL query (same AZ)          1–5 ms
Disk (HDD) seek                             5–10 ms
Read 1 MB sequentially from HDD             5–20 ms
Round trip across AZs in a region           1–2 ms
Round trip US-East ↔ US-West                ~70 ms
Round trip US ↔ Europe                      ~80–100 ms
Round trip US ↔ India / Australia           ~150–250 ms
TLS 1.3 handshake (new connection)          1 RTT (+ TCP 1 RTT)

EstimationTemplate.mdmarkdown

The 60-second sizing recipe. Worked for a photo-sharing app.

ASSUME   100M DAU, each uploads 0.1 photo/day and views 50/day
WRITES   100M × 0.1 / 10^5 s       = 100 uploads/s   (peak ×3 → 300/s)
READS    100M × 50  / 10^5 s       = 50k views/s     (peak → 150k/s)
RATIO    read:write = 500:1         → cache + CDN dominate the design
STORAGE  10M photos/day × 1 MB      = 10 TB/day
         × 365 × 5 years            ≈ 18 PB  (× replication factor!)
EGRESS   50k/s × 200 KB (resized)   = 10 GB/s → must be a CDN, not origin
METADATA 10M/day × 500 B            = 5 GB/day → ~9 TB over 5y, shard later
DECISION → object store + CDN for bytes, sharded KV/SQL for metadata,
           async resize pipeline, heavy edge caching.

Explain without notes

Why can't a synchronous request path afford five sequential cross-region calls, however fast each service is?

Convert 500M events/day into average and peak events/second, out loud, in under 15 seconds.

Practice

Size WhatsApp: 2B users, 50 messages/user/day, 100 bytes each. Work out messages/s, storage/day, and 5-year storage.

Size YouTube uploads: 500 hours uploaded per minute, stored in 5 renditions averaging 1 GB/hour. Work out storage per day.

Trade-offs

↔
Precision vs speed: interviewers want the right order of magnitude and a decision it drives, not three decimal places. Spending 10 minutes on arithmetic is a negative signal.

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

Networking · Latency, bandwidth & throughput

Measure the numbers yourself with real tools.

Stateful · Bottlenecks & capacity planning

USE/RED, Little's Law, the utilisation knee, and profilers.

Completion checklist

I can recite the latency ladder from L1 to cross-continent RTT.
I can size QPS, storage, and bandwidth for any prompt in under two minutes, with each number tied to a decision.

Back to phase

Command Palette