A Kafka cluster needs to preserve its metadata when a controller fails. In KRaft, controllers form a quorum to manage that metadata. One controller leads; followers fetch its updates. An update becomes committed only after a majority has replicated it, so a newly elected leader retains committed entries. section 9.1 section 9.1.1
Figure 9.2 Metadata updates are sent to the leader controller, which appends each update to its log. Follower controllers fetch these updates from the leader, and once a majority have replicated the update, it is marked as committed.
Follow an update from the leader controller’s log to the followers, then to majority replication and commitment. section 9.1.1
This quorum governs cluster metadata, not ordinary topic replication. Controllers write the Raft metadata log; brokers can keep a local read-only copy and serve metadata to clients. Broker replication has configurable consistency and does not use this quorum acknowledgment rule. section 9.1.1
Sizing for a controller failure
To tolerate one controller failure, run three controllers: two still make a majority. More generally, tolerating N controller failures calls for 2N + 1 controllers. If the majority is lost, leader elections and metadata changes halt. Placement matters too: spreading controllers across three data centers can preserve quorum after one entire data center fails, whereas a two-data-center layout can lose its majority. section 9.5 section 9.1.1
Older Kafka deployments may instead use a separate ZooKeeper cluster for metadata and broker-liveness monitoring. ZooKeeper’s ZAB protocol also requires majority acknowledgment, but its replication and commit sequence differs from KRaft’s. Identify the metadata architecture before planning controller placement, monitoring, or failure response. section 9.1.4 section 9.5
