Why Is Kafka Fast? Sequential I/O and Zero-Copy Explained

Isn't disk supposed to be slow? Way slower than memory? So why is it that Kafka — one of the fastest message queues running in production anywhere — deliberately writes everything to disk? That sounds like a contradiction. But here's the thing: it isn't. Whether disk is fast or slow doesn't depend on the disk. It depends on *how* you talk to it. And Kafka's entire performance story comes down to access patterns.

Let's start with the myth that disk is slow. On a traditional spinning hard drive, there's a physical mechanical arm. Every time it has to jump to a different spot on the platter to find your data, that seek takes something like five to ten milliseconds. Now, five milliseconds sounds tiny to us, but in that same window a modern CPU can rip through tens of millions of instructions. So the arm is the bottleneck. That's the real villain — not the disk itself, but *random* access, all that jumping around.

Now flip it. What if you never jump? What if every read and every write just continues right where the last one left off? That's sequential access, and suddenly seek time basically disappears. A plain hard drive can push five hundred megabytes a second or more when it's going sequentially, and an SSD blows way past that.

And there's a bonus. When the operating system notices you're reading in order, it starts guessing ahead — it's called read-ahead. The kernel pre-loads the next chunk you're probably going to want, before you even ask for it. So disk starts to *feel* like memory.

Here's where Kafka's design clicks into place. A Kafka topic partition is just an append-only log file. Producers only ever add to the end. Consumers only ever read forward from a given position. The read head marches in one direction, always. That's the whole trick — Kafka structured its data so that the disk's one weakness, seeking, just never comes up.

Which brings us to the second pillar: the page cache. The Linux kernel keeps this layer in memory called the page cache. When you read something off disk, the kernel quietly stashes a copy in RAM. Ask for that same data again, and it comes straight from memory — the disk never gets touched.

Now, a lot of systems fight the OS here. They build their own in-memory buffer, manage their own cache, try to be clever. Kafka does the opposite. It leans hard on the page cache and lets the operating system do the work. And that pays off in three big ways.

First, the JVM stays lean. The Kafka broker's heap can be small, because it's not hoarding data in memory — the OS is handling that. Small heap means way less garbage collection pressure.

Second — and this one's beautiful — the cache survives a restart. If Kafka's memory lived in the JVM heap, restarting the process would wipe it clean. But the page cache belongs to the OS, not to Kafka. So you can bounce the Kafka process and the cache is still sitting there warm. Consumers keep getting hits.

Third, when consumers are keeping up with producers, consumption is almost free. Think about it: a message a producer just wrote is *already* in the page cache. So when the consumer comes along a moment later to read it, it never has to reach down to the physical disk at all. It's already in memory.

This is exactly why the recommendation for Kafka is to give most of your broker's RAM to the operating system, not to the JVM heap. You *want* the OS to spend that memory on page cache. That's where your speed lives.

Okay, third pillar, and this is my favorite: zero-copy. Let's trace what normally happens when a server reads a file off disk and sends it over the network. The data goes from disk into a kernel buffer — that's the page cache. Then it gets copied up into a user-space buffer, into your application. Then copied into a socket buffer. Then finally out to the network card. Count them: that's four copies of the same bytes, and four context switches back and forth between user space and kernel space. All of that just to shovel data from disk to network — data your application never even needed to look at.

Kafka says, why are we dragging this up into user space at all? So it uses a system call — `sendfile` on Linux, or `transferTo` in Java's NIO — that tells the kernel: take this data from the page cache and send it straight to the network card. Now the path is disk, to kernel buffer, to network card. Two copies instead of four. Two context switches instead of four. And the best part — the CPU doesn't touch the data at all. The actual transfer is handled by the DMA controller, Direct Memory Access, dedicated hardware whose entire job is moving bytes so the CPU doesn't have to. When you're running at several gigabytes a second, cutting out those copies and freeing up those CPU cycles turns directly into real, measurable throughput and lower latency.

And then there's the multiplier on top of all of it: batching. Every optimization we've talked about compounds when you batch. The producer packs a bunch of messages into one batch before sending — one system call carries many messages instead of one at a time. The consumer pulls a whole batch per request — fewer network round trips. And compression works dramatically better on a batch, because a pile of similar-looking messages squeezes down far more than each one would alone. Kafka gives you gzip, snappy, lz4, and zstd to choose from. When your bottleneck is network bandwidth, compression can be the exact thing that gets you over the line to your throughput target.

So step back and look at the bet Kafka made. An append-only log, where consumers track their own position — their own offset. Because nothing ever gets deleted or modified, reads are *always* sequential. And because each consumer remembers where it is, the broker doesn't have to babysit per-message delivery state for everybody. That simplicity is the foundation. It's what lets the sequential assumption hold, and *that's* what makes page cache and zero-copy actually work. It's not three unrelated tricks — it's one design decision paying off three times.

So the three things to walk away with. One: disk isn't slow, random access is slow — and Kafka's append-only log makes every access sequential, so the disk's weakness never shows up. Two: Kafka hands memory management to the OS page cache instead of hoarding it in the JVM, which keeps it lean and keeps the cache warm even across restarts. And three: zero-copy sends data straight from page cache to the network card, no CPU, no wasted copies. Underneath all of it is that one elegant bet — the append-only log — and everything else is just that bet cashing in. Next time, we'll get into partitions, replication, and how consumer groups let Kafka scale out sideways.