How Kafka Hits Million‑Message Throughput Using Page Cache and Zero‑Copy

Page Cache and Sequential Disk Writes

When a producer sends a record to Kafka, the broker writes the record to a log file. The write is first performed against the operating system’s page cache (OS cache) which resides in RAM. The kernel decides when to flush the cached pages to the underlying storage device. Because the data is initially written only to memory, write latency is reduced to the order of a few microseconds.

Kafka appends records to the end of the log file, never overwriting existing bytes. This results in strictly sequential disk I/O. Sequential writes avoid the seek and rotational latency of random writes on magnetic disks and allow modern SSDs and HDDs to approach the throughput of pure memory writes. Combined, page‑cache writes and sequential appends enable a single broker to sustain tens to hundreds of thousands of writes per second.

Zero‑Copy Consumption

Reading data without zero‑copy would involve:

Check if the required bytes are already present in the OS page cache; if not, read them from the storage device into the cache.

Copy the bytes from the page cache into the consumer process’s user‑space buffer.

Copy the bytes from the user buffer into the kernel socket buffer.

Transmit the socket buffer to the network interface.

Steps 2 and 3 cause two memory copies and multiple context switches, which increase latency and CPU usage.

Kafka uses the sendfile() system call (or equivalent splice mechanisms) to implement zero‑copy. The kernel transfers data directly from the page cache to the socket, passing only a file descriptor. No user‑space buffer is involved, eliminating the two copies and reducing context switches.

When the data is already resident in the page cache, the read path becomes a pure memory‑to‑network operation, dramatically increasing consumer throughput.

Key Takeaways

Kafka relies on the OS page cache for both writes and reads, turning most I/O into memory operations.

Log files are written by appending only, guaranteeing sequential disk access and high write throughput.

Zero‑copy (via sendfile or splice) removes unnecessary memory copies during consumption, lowering latency and CPU overhead.

These design choices allow a well‑tuned broker to handle tens of thousands to millions of messages per second.