Why this matters in production: the version of this you'll actually hit is a database page, not a cache line — same idea, larger unit. Postgres reads and writes in 8 KB pages. Asking for one 200-byte row costs a full 8 KB page read, and the other rows on that page are now cheap. Whether the rows you want next are on that page is decided by your insert order and your index — which is precisely the mechanism Module P-3 uses to explain how random UUID keys destroy insert performance.

---

Latency vs Throughput, and Why Both Are Needed

These get used interchangeably and mean different things.

Latency is how long one operation takes. Throughput is how many operations complete per unit time. They're related but not reciprocal, because operations run in parallel.

A single NVMe random 4 KB read takes ~50 µs of latency. That does not mean the device does 20,000 reads/second. A modern NVMe drive has many independent queues and will happily service hundreds of requests concurrently, delivering 500,000+ IOPS while each individual read still takes ~50 µs. Latency stayed the same; throughput went up 25× through queue depth — how many requests are in flight at once.

This distinction is why:

• A single-threaded process issuing one blocking read at a time gets a tiny fraction of a device's capability, no matter how fast the device is. Concurrency is what converts latency into throughput.
• Benchmarks are meaningless without stating queue depth. "4K random read IOPS" at QD1 and QD32 differ by more than an order of magnitude on the same drive.
• Adding load to a system near saturation increases latency without increasing throughput — the requests queue instead of completing. Module F-4 formalises this with Little's Law, and Module A-8 turns it into a load-shedding strategy.

Rules of thumb worth carrying:

Look at the HDD row. Sequential throughput is within 3× of a SATA SSD; random IOPS is worse by a factor of ~500. A spinning disk isn't uniformly slow — it's catastrophically slow at random access specifically, because each seek moves a physical arm. That asymmetry is why the entire first generation of database design was organised around avoiding seeks, and why those designs still pay off on SSDs where the asymmetry is smaller but real.

---

The Fact That Explains Everything Later

Here is the claim, stated precisely, because the sloppy version of it is wrong:

Measured in useful bytes per second, a sequential write to an SSD beats a random-access pattern in DRAM.

Work through it:

• Random access in DRAM: each access costs ~100 ns and, if you only use a few bytes of the cache line you pulled in, you get ~8 useful bytes per access. That's ~10M accesses/second × 8 bytes = ~80 MB/s of useful data.
• Sequential write to NVMe: ~3,000 MB/s, and every byte is useful.

So the sequential SSD write delivers roughly 35× more useful throughput than the random memory access pattern. Not because the SSD is faster than RAM — it isn't, by any measure of a single operation — but because access pattern beats storage medium by a wider margin than people expect.

Two caveats to keep this honest, both of which matter in practice:

1. This is a throughput claim, not a latency claim. One random DRAM read (~100 ns) is ~500× faster than one NVMe write (~50 µs). If you need one small value right now, memory wins overwhelmingly. The sequential-wins result applies when you're moving bulk data.
2. Sequential access in DRAM is far faster than either — 20–50 GB/s, since the prefetcher and full cache-line utilisation both work for you. The comparison above is deliberately worst-case-memory against best-case-disk to make the size of the access-pattern effect visible.

With that stated properly, the payoff chain for the rest of the course:

• Kafka (Module P-15) writes every message by appending to a file and lets consumers read sequentially. It is not fast despite using disk; it's fast because an append-only log is the access pattern disks are best at. Kafka's own design notes make exactly this argument.
• LSM-trees (Module P-2) — the engine behind Cassandra, RocksDB, ScyllaDB, and LevelDB — buffer writes in memory and flush them as large sequential files, deliberately converting random writes into sequential ones. The cost, named honestly, is read amplification and compaction: you pay later, in background I/O.
• B-trees (Modules F-13, P-2) — Postgres, MySQL/InnoDB — update pages in place, which means writes land wherever the key belongs. Sequential keys keep those writes clustered; random keys scatter them across the whole index.
• Random UUID primary keys (Module P-3) are the failure mode of that last point. Each insert targets a random leaf page, so the working set of "pages currently being written" becomes the entire index rather than the last few pages. Page splits go up, cache hit ratio goes down, and WAL traffic multiplies. Same insert, same complexity class, a completely different physical access pattern.
• FinOps (Module O-8) closes the loop: provisioned IOPS is a line item on a cloud bill. An access pattern that needs 10× the IOPS costs 10× more, forever.

---

The Page Cache and What fsync Really Costs

One more layer, because it's where "the write succeeded" gets ambiguous.

When your process writes to a file, the data normally lands in the OS page cache — RAM managed by the kernel — and the write call returns. The kernel flushes it to the device later. This is why writes often look impossibly fast: you measured a memory copy, not a disk write.

fsync() (or fdatasync()) forces the kernel to push that data to the device and wait for the device to confirm it's durable. That's the difference between "the OS has my data" and "my data survives a power cut," and it costs one device round trip — hundreds of microseconds on NVMe, and historically milliseconds on anything with a rotating platter.

This single call is why:

• Databases batch commits. Postgres's commit_delay and group commit exist to amortise one fsync across many transactions. synchronous_commit = off makes commits dramatically faster by not waiting — trading a window of possible data loss for throughput, which is the trade-off stated plainly.
• Durability is a spectrum, not a boolean. "Written" can mean in the application buffer, in the page cache, on the device, or on the devices of two replicas in different availability zones. Each step is slower and safer. Modules P-5 and O-7 depend on being precise about which one you meant.
• Cloud block storage adds a network hop. An EBS volume is not a local disk; a durable write there is a network round trip inside the datacentre (~0.5 ms) plus replication on their side. Local NVMe instance storage is far faster and disappears when the instance stops — a genuine trade, not a free upgrade.

---

Where This Shows Up in Your Stack

• PostgreSQL: shared_buffers is Postgres's own page cache, and the ratio in pg_statio_user_tables (heap blocks hit vs read) is a direct measure of whether your working set fits in memory. A query plan that switches from an index scan to a sequential scan isn't necessarily a regression — for a large fraction of a table, one sequential read at 3 GB/s genuinely beats a million random 8 KB page fetches, and the planner is doing this exact arithmetic (Module F-13).
• Redis: the reason Redis is fast is that it eliminated the slowest layer entirely — data is in RAM, so every operation is a ~100 ns access rather than a ~50 µs one. That's the whole trick, and its cost is that your dataset must fit in memory and durability requires deliberate configuration (AOF appendfsync is exactly the fsync trade-off above).
• Node.js: JSON.parse on a large payload allocates a graph of scattered heap objects; the parse cost you measure is substantially memory-layout cost, not parsing logic. Streaming (Readable) processes bounded chunks that stay resident in cache rather than materialising a huge object graph — that's a cache-friendliness win as much as a memory-ceiling win.
• Kafka and object storage: both are throughput-optimised systems that assume sequential access. Using Kafka as a random-access key-value store, or S3 as a database with many small ranged reads, fights the medium and produces exactly the latency you'd predict from the table above.

---

Summary

• Know the hierarchy in human time: L1 ~1 s, DRAM ~1.5 min, NVMe read ~14 hours, cross-continent round trip ~6 years (at 1 ns = 1 s). Distance dominates.
• Memory arrives in 64-byte cache lines, and hardware prefetchers reward predictable strides. Two O(n) scans can differ by 10× purely from layout — the constant factor Big-O hides.
• Latency and throughput are different axes. Queue depth and concurrency convert a fixed latency into much higher throughput; near saturation, added load raises latency without raising throughput.
• Random access is the expensive thing, not disk. HDDs do ~100–200 random IOPS but 150–250 MB/s sequential; NVMe narrows the gap without closing it.
• In useful bytes/second, a sequential SSD write (~3 GB/s) beats a random DRAM access pattern (~80 MB/s) — a throughput claim, not a latency one. Sequential DRAM still beats both.
• That fact is the design origin of Kafka's log, LSM-trees, and the UUID-key problem, and it ends up on your cloud bill as provisioned IOPS.
• fsync is the boundary between "the OS has it" and "it survived a power cut," costing one device round trip. Durability is a spectrum; say which point on it you mean.

The next module, Back-of-the-Envelope Estimation, puts these numbers to work. Now that you know what a disk seek and a memory access actually cost, you can size a system in five minutes and be confident you're within an order of magnitude — which is all any early design decision needs.

---