Why Kafka Is Fast: Sequential I/O, Page Cache, Zero-Copy

In one line

Kafka appends sequentially, lets the OS page cache hold hot data (not the JVM heap), serves consumers straight from the page cache with sendfile zero-copy, and batches and compresses everything end to end, so one broker can move hundreds of MB/s on modest hardware.

0/6 · 0%

Think of it like this

A busy train station. Trains (batches) carry many passengers at once, run on fixed tracks one after another (sequential writes), passengers waiting on the platform are served instantly without going back to the ticket office (page cache), and luggage goes directly from the train to the platform without passing through the station's office (zero-copy).

Key ideas

01
Sequential writes: appending to the end of a file is the fastest disk access pattern (hundreds of MB/s even on HDDs, much more on SSDs), unlike random updates of B-tree databases.
02
Page cache: Kafka writes to the OS page cache and relies on the OS to flush; recent data stays in memory. Consumers reading near the end of the log (the common case) are served from memory. That's why brokers use a modest JVM heap (for example 6 GB) and leave most RAM to the OS.
03
Zero-copy: for non-TLS consumers, the broker uses sendfile to move bytes from the page cache to the network socket inside the kernel, without copying through JVM buffers. Records stay in the same batch format producers wrote, so no re-encoding is needed. TLS prevents zero-copy (encryption happens in user space), which is one reason TLS costs broker CPU.
04
Batching everywhere: producer batches, compressed once, stored as-is, replicated as-is, fetched as-is, decompressed only by consumers.
05
Partition parallelism: many partitions spread I/O across disks and brokers. Consumers that fall far behind read old data from disk (cold reads), which is slower and can evict hot data from the page cache, hurting everyone.

Code & diagrams

zero-copy.mermaiddiagram

Rendering diagram…

broker-memory.txttext

Broker host: 64 GB RAM
  JVM heap (-Xms6g -Xmx6g, G1GC)       6 GB   request handling, metadata, buffers
  OS page cache                      ~55 GB   recent log segments: most consumer reads hit here
  OS and other                        ~3 GB
Rule of thumb: page cache should hold roughly (write MB/s x seconds of lag you expect consumers to have)

Explain it without notes

Why does Kafka keep a small JVM heap and rely on the page cache?

Practice

Run a consumer reading from the beginning of a large topic while producers write, and watch broker disk read I/O with iostat.

Trade-offs

↔
TLS and cold reads disable Kafka's cheapest paths (zero-copy, page cache hits), costing CPU and I/O.

Done when you can

I can explain sequential I/O, page cache, zero-copy and batching as the sources of Kafka's speed.