Unveiling Kafka’s Triple‑High Architecture: Availability, Performance, and Concurrency

1. Kafka High‑Availability Design

Kafka elects a single broker as the Controller using a temporary Zookeeper node /controller. The first broker that creates this node becomes the controller, which manages partition and replica states. Leader election follows a similar pattern: brokers compete to create a temporary node; the winner becomes the partition leader.

Controller startup steps:

The first broker creates /controller in Zookeeper and registers itself.

Subsequent brokers attempt to create the node, fail, and recognize that a controller already exists.

All brokers register listeners on the controller to monitor state changes.

2. Replica and ISR Mechanisms

Each partition has multiple replicas for redundancy. One replica is the Leader ; the others are Followers . The leader handles all writes, and followers replicate the leader’s log. Kafka stores replica information in Zookeeper under paths such as /brokers/topics/[topic]/partitions/[partition]/state.

The ISR (In‑Sync Replica) list contains all replicas that are fully caught up with the leader. A follower stays in ISR if it sends heartbeats to Zookeeper and fetches data from the leader within replica.lag.time.max.ms (default 10 s). If a follower falls behind, it is removed from ISR until it catches up again.

3. ACK Configuration

The producer’s acks setting determines durability: acks=0: Producer does not wait for broker response; highest throughput but possible data loss. acks=1: Leader acknowledges after writing to its log; may lose data if the leader fails before followers replicate. acks=all (or -1): Leader waits for all in‑sync replicas; combined with min.insync.replicas it tolerates up to min.insync.replicas‑1 replica failures.

4. Reactor (NIO) Model in Kafka

Kafka’s SocketServer is built on Java NIO using a Reactor pattern with three roles:

Acceptor : Listens for new connections (OP_ACCEPT).

Processor : A pool of threads, each with its own Selector, handling read/write events for assigned connections.

Handler : Executes business logic after a request is parsed.

Connections are distributed round‑robin to Processor threads, and each Processor registers OP_READ on its Selector. Parsed requests are placed into a RequestQueue, processed by a pool of RequestHandler threads, and responses are queued in a ResponseQueue before being written back via OP_WRITE.

5. Producer Message Flow

When a producer sends a record:

The record is wrapped in a ProducerRecord and serialized.

The partitioner determines the target topic partition using cluster metadata.

Before Kafka 0.8, each record triggered an immediate request; since 0.8, records are buffered in a RecordAccumulator and sent in batches ( RecordBatch).

A sender thread converts full batches into a single request, reducing network calls.

Batch size defaults to 16 KB; if not full, the batch is flushed after linger.ms (500 ms).

To avoid frequent GC, Kafka uses a memory‑pool of 32 MB divided into 16 KB blocks. Batches acquire blocks from the pool, and after sending, blocks are returned for reuse, dramatically lowering GC pressure.

6. Zero‑Copy I/O

Kafka minimizes data copies by using OS page cache for writes and employing zero‑copy techniques for reads: mmap (via MappedByteBuffer) maps log files directly into memory. FileChannel.transferTo (or sendfile on Linux) transfers bytes from the file descriptor to the socket without copying into user space.

This reduces two memory copies and context switches, improving throughput.

7. Compression

Kafka supports several compression algorithms (lz4, snappy, gzip, zstd). Compression is applied on the producer side, stored compressed on the broker, and decompressed by the consumer only when delivering messages, saving network bandwidth and disk I/O.

8. High‑Concurrency Network Design

The network stack is a three‑layer architecture:

Acceptor layer : Accepts connections and creates SocketChannel objects.

Processor layer : Multiple Processor threads (default 3) each hold a connection queue and register OP_READ on their Selectors. They parse incoming bytes into Request objects and push them to the second‑layer queue.

RequestHandler layer : A pool (default 8) pulls requests from the RequestQueue, writes data to disk, creates Response objects, and places them into ResponseQueues. Processor threads then register OP_WRITE to send responses back.

Key tunable parameters are num.network.threads and num.io.threads. Increasing them (e.g., to 9 and 32 respectively) can raise per‑thread QPS from 2 000 to 6 400, allowing the cluster to handle >60 000 QPS.

9. Summary

The article has dissected Kafka’s “three‑high” architecture—high availability, high performance, and high concurrency—covering controller election, replica/ISR handling, ACK semantics, NIO‑based Reactor model, producer batching, memory pooling, zero‑copy I/O, compression, and the multi‑layer network threading model.