Kafka Controller: KRaft Quorum vs ZooKeeper

The controller is the broker responsible for cluster coordination — it elects partition leaders when a broker dies, updates the ISR, and propagates topic creation and ACL changes. Importantly, the controller is not in the data path; it doesn't touch produce or consume traffic.

The historical model used ZooKeeper:

• Brokers registered themselves as ephemeral znodes; the controller was elected by being the first to create /controller in ZooKeeper
• Cluster metadata — brokers, topics, partition assignments, configs — lived in ZK
• The downside was operating two distributed systems and a hard scaling ceiling around 200,000 partitions per cluster, with controller failover that took minutes because the new controller had to reload all metadata from ZK

KRaft replaces ZooKeeper:

• A small set of brokers, typically 3 or 5, are designated as controller.quorum.voters and run Raft consensus among themselves
• Cluster metadata is stored as an append-only log in the internal __cluster_metadata topic
• Every other broker tails that log to learn cluster state, the same way ordinary consumers tail any topic
• Failover is sub-second because every voter already has the metadata in memory; clusters now scale comfortably to millions of partitions

Operational impact:

• One distributed system instead of two — no separate ZK to deploy, monitor, patch, secure, and back up
• Faster broker startup, faster controller failover, simpler single-binary deployments
• Kafka 4.0 removed ZooKeeper support entirely; existing ZK clusters need to use the KIP-866 migration path

For any new cluster I default to KRaft with a dedicated 3-node controller quorum separate from the data brokers, because it gives the cleanest operational model and matches where the project is going.