Why These Numbers Matter
To design a fast system, you need an intuition for what "fast" actually means at the hardware level. Without this, you might propose a design that makes 10 sequential database calls per user request and not realize that you've just added 100ms of latency to every page load. These numbers, popularized by Google Fellow Jeff Dean, give you that intuition.
The Numbers (Approximate, 2020s Hardware)
| Operation | Latency | Human Analogy |
|---|---|---|
| L1 Cache Reference | 0.5 ns | 1 second |
| L2 Cache Reference | 5 ns | 10 seconds |
| RAM Reference | 100 ns | 3 minutes |
| SSD Random Read | 150,000 ns (150 µs) | 3 days |
| HDD Disk Seek | 10,000,000 ns (10 ms) | 7 months |
| Packet: same datacenter | 500,000 ns (0.5 ms) | 2 weeks |
| Packet: cross-continent | 150,000,000 ns (150 ms) | 10 years |
(The human analogy scales everything so that an L1 cache read = 1 second, making the relative differences visceral.)
The Three Rules You Must Internalize
Rule 1: RAM is ~1,000x faster than SSD, which is ~100x faster than HDD.
This is why we use Redis or Memcached as a caching layer. A cache hit costs ~100ns; a database read from disk costs ~10ms. That's a 100,000x difference. If your hot data fits in RAM, put it there.
Rule 2: Avoid random disk seeks. Sequential reads/writes are dramatically faster.
An HDD can do ~100 random seeks per second but can read sequentially at ~100 MB/s. This is why databases use append-only write-ahead logs (WAL) and why Kafka writes messages sequentially to disk — sequential I/O is predictable and fast.
Rule 3: Network calls across datacenters are expensive. Batch them.
A cross-continent round trip costs ~300ms. If your service makes 5 sequential cross-datacenter calls per request, you've already spent 1.5 seconds before doing any real work. Design for locality (keep data close to compute) and batching (combine multiple operations into one network call).
Interviewers frequently ask: "Why would you use Redis instead of just querying the database?" The answer is not "because Redis is faster" — that's vague. The precise answer is: "A Redis read from RAM costs ~100 microseconds. A PostgreSQL read requiring a disk seek costs ~10 milliseconds. For a hot-path endpoint serving thousands of requests per second, that 100x latency difference is the difference between a responsive product and a broken one. Redis also reduces read load on the primary database, which protects write throughput."