Numbers to Know

In the age of search engines, memorizing numbers sounds quaint — until you watch a strong engineer work. Ask one "can we call the pricing service inside the checkout loop?" and they answer in five seconds: "that's a cross-datacenter hop per item, call it half a millisecond times forty items — 20 ms, fine." No tab was opened. The numbers were loaded, and that's what made the five-second answer — and last lesson's whole envelope method — possible at all.

This is the famous table — the one Jeff Dean's talks made canonical and every engineer eventually tapes to their monitor — brought to 2026 and organized the way memory actually works: a dozen latencies, a handful of throughputs, the sizes of common things, and what one box can do. You've already met the latency ladder twice in this course (the OS chapter built it; the caching chapter weaponized it) — today it becomes part of your permanent equipment, alongside the numbers it was missing.

Two promises about this lesson. First: you don't need the absolute values nearly as much as the ratios — and the ratios are unforgettable once you've used them, which is what the composer below is for. Second: we'll sort the numbers into the two kinds nobody tells you about — the ones that keep shrinking as hardware improves, and the ones that are physics and will outlive every processor ever made.

The core dozen, same figures this course has used from the start — with the human-scale trick (pretend 1 nanosecond = 1 second) that turns exponents into gut feelings:

Three footnotes that make this the 2026 edition rather than the 2012 one:

• Modern NVMe beats the classic SSD number — high-end drives do random reads in 20–50 µs. Keep ~150 µs as your safe planning number; enjoy the upside when the hardware is newer.
• The disk-seek number hasn't meaningfully moved in thirty years. It's a mechanical arm physically swinging across a platter; no process shrink helps. That's why SSDs rearranged system design.
• The network numbers are geography. ~5 ms per 1,000 km (one way, in fibre) — the measurement lesson's physics floor. A transpacific round trip has been ~130–150 ms for decades and will stay there.

If the table feels like a lot, relax — you're not memorizing twelve numbers. You're memorizing about four, plus the ratios between them.

Here's the compression trick: absolute numbers fade, but ratios stick — and ratios are what estimation actually uses. The four worth carving into stone:

• RAM : SSD ≈ 1 : 1,500. Everything the caching chapter proved hangs on this one gap.
• SSD : disk seek ≈ 1 : 70. Why "just add an index" (turning seeks into a few reads) and "move it to SSD" were the two great database speedups of a generation.
• A datacenter hop ≈ 3 SSD reads (~500 µs). Every microservice call you add costs about as much as reading three things from local flash — a ratio that quietly prices your architecture diagrams.
• A cross-region hop ≈ 300 datacenter hops ≈ 1,000,000 RAM reads. One number that explains CDNs, regional replicas, and why "just call the other region" is never just.

Stack them and you get the full ladder: 1 : 1,500 : 100,000 : 1,500,000 from RAM to SSD to disk-or-DC-crossing to crossing an ocean. Say it in sentences: touching flash costs you a thousand RAM reads; touching another machine costs a few flash reads; touching another continent costs everything. An engineer who knows only that sentence out-estimates one who once memorized the table and forgot it.

Latency says how long one thing takes; throughput says how much fits through the pipe — and the measurement lesson warned you they're independent axes. The 2026 pipe sizes:

Two anchors to keep:

• A spinning disk and a gigabit link are the same size (~150–200 MB/s). One mental slot, two facts.
• Sequential versus random is a bigger deal than the device. A disk doing sequential streams respectably; the same disk doing random seeks collapses by 1,000×. This is why databases are obsessed with append-only logs and why Kafka (⟵ the async chapter) is fast on spinning rust.

And the practical composite: to move 1 TB across a 10 Gbps link takes 1 TB ÷ 1.25 GB/s ≈ 13 minutes; across a 100 MB/s effective WAN, ~3 hours. Numbers like these are why "ship the drives" is sometimes a real answer (AWS literally sells a truck).

Reading a table stores it in short-term memory. Spending the numbers stores them for good. Below, build requests out of the actual figures — add RAM reads, SSD reads, disk seeks, datacenter hops, cross-region hops — and watch the total assemble, in real units and on the human scale.

Do this in order:

1. Load the cache hit preset (one DC hop + one RAM read): ~0.5 ms — the hop is the cost; the RAM read is a rounding error. Now swap in the indexed DB read (a hop + two SSD reads): still under a millisecond. This is why a well-indexed database feels free.
2. Load old-school disk read — same request, one disk seek instead of SSD: 10 ms, twenty times worse, four months on the human scale. One chip changed; the request changed class.
3. Load the N+1 bug: twenty-five little queries, each paying its own datacenter hop, instead of one batched query — ~16 ms of pure architecture tax. Then batch it back down and watch 25 hops collapse to 1. You've just debugged the most common performance bug in web history, numerically.
4. Add a single cross-region hop to anything: 150 ms lands like a hammer — it outweighs a thousand RAM reads a thousand times over. Now you know why every chapter of this course keeps trying to avoid that hop.

Type a latency budget (say, 100 ms) and watch the verdict flip as you compose. The ops/s readout shows the other face of the same number: a worker stuck doing 10 ms disk seeks maxes out at 100 sequential operations a second — throughput is latency's shadow.

Storage estimates die without size intuition. The bytes worth knowing cold:

Now the reflex from last lesson, which converts these into capacity plans in one move: millions × KB = GB; billions × KB = TB; millions × MB = TB. Ten million users × a 1 KB profile = 10 GB — fits in RAM on one box. A billion tweets × 300 B = 300 GB — one beefy SSD. Ten million photos × ½ MB = 5 TB — now we're talking real storage. The instinct to build: text is almost free, metadata is cheap, images are real money, and video is its own department.

The most sanity-saving numbers on the sheet — because the most common estimation failure isn't bad arithmetic, it's not knowing what normal is. The 2026 anchors:

• A commodity server: 32–64 cores, 128–512 GB RAM, a few NVMe TB, a 10–25 Gbps NIC. (Rentable by the hour. Not exotic.)
• nginx serving static/proxying: ~10K–100K requests/s.
• An application server doing real work: ~1K–10K requests/s.
• PostgreSQL, simple indexed queries: ~5–10K QPS.
• Redis: ~100K+ ops/s (a million with pipelining).
• A Kafka broker: ~100K+ messages/s.

Hold these against last lesson's envelope: our photo app peaked at 10K QPS — which you can now place: a handful of app servers, one respectable Postgres (with the caching chapter carrying the reads), Redis barely awake. Most systems people nervously architect for fit on a shockingly small number of machines — and knowing that is the difference between designing calmly and cargo-culting a planet-scale architecture for 200 QPS. (What does change as QPS grows 100× is the closing lesson of this section.)

Every numbers table ages — the 1990s version of this lesson had disk seeks at the center of the universe. So file each number by its trajectory, and your sheet stays useful for a decade:

Shrinking on a curve: CPU and cache speeds, RAM prices, flash everything (the classic 150 µs SSD read is already 20–50 µs on modern NVMe), NIC bandwidth (10 → 25 → 100 Gbps marches on). Rule: silicon numbers improve; re-check them every few years.

Frozen forever: the speed of light (5 ms per 1,000 km — cross-region RTTs have been flat for decades and always will be), and mechanical motion (a disk arm seeks today at nearly the same speed as in 1995 — which is why spinning disks retreated to sequential, archival work). Rule: geography and mechanics don't patch.

This split is quietly load-bearing for your whole career: architectures built on shrinking numbers get better for free (your SSD-based design speeds up every hardware refresh), while architectures that fight physics (chatty cross-region calls) are permanently, unfixably slow. When in doubt, design against the frozen numbers and let the shrinking ones surprise you pleasantly.

• "I can look numbers up when I need them." Estimation is a conversation-speed skill — by the time the tab loads, the design review moved on. The dozen numbers are the vocabulary, not trivia.
• "A UUID is 16 bytes." In binary, yes — as a string it's 36, and half the schemas in the world store it as a string. A 2× storage estimate error hiding in one column.
• "10 Gbps network = 10 GB/s." ÷8. Bits for pipes, bytes for payloads (the guardrail from last lesson — it will never stop trying to bite you).
• "Disks read at 200 MB/s, so my random-read workload is fine." Sequential 200 MB/s; random ~150 IOPS. The access pattern, not the device, decides which number you get.
• "Redis does 100K ops/s, so my app will." Anchors are ceilings for that component, not your end-to-end number — your request also pays app work, hops, and the slowest stage wins (⟵ the knee, the tail, and everything the measurement lesson taught).
• "The table said 150 µs, my drive does 30 — the table is wrong." Planning numbers are conservative on purpose. Estimate with the safe number; celebrate the faster hardware in production.

• The dozen latencies, on the human scale: RAM ~100 ns (minutes) · SSD ~150 µs (days) · DC hop ~500 µs (days) · disk seek ~10 ms (months) · cross-region ~150 ms (years). Carry the ratios: 1 : 1,500 : 100,000 : 1,500,000 — flash costs a thousand RAMs, another continent costs everything.
• Throughput: disk ≈ gigabit link (~200 MB/s, one mental slot) · NVMe in GB/s · 10 Gbps = 1.25 GB/s · sequential ≫ random is bigger than any device choice.
• Sizes: everything's 8 bytes until it's a string (UUID: 16 → 36!) · text tiny, photos ~½ MB, video ~5 GB/hr · millions × KB = GB.
• One box does more than you fear: Postgres ~5–10K QPS, Redis ~100K ops/s, nginx ~10K–100K RPS — most designs fit on few machines, and knowing normal is the best defense against cargo-cult architecture.
• File every number by trajectory: silicon shrinks, physics and mechanics never do — design against the frozen numbers.

You now hold the method (last lesson) and the numbers (this one). Next — Estimation Walkthroughs: QPS, Storage, Bandwidth — we put both to work on three complete, honest, narrated calculations, the exact kind an interview or a design review asks for.