Explain how quorum-based election works in Kafka for controller election and its impact on cluster stability.

Official answer

Kafka 4.x uses KRaft, a Raft-based metadata quorum. Controller voters maintain the metadata log and elect an active controller. This is different from older ZooKeeper-based deployments, in which a broker held the controller role.

A candidate must obtain the required majority of controller voters to become leader under the protocol. Metadata decisions are committed through quorum replication. Election epochs and log checks prevent an isolated minority from independently committing a competing metadata history. Do not implement a recovery shortcut by starting unrelated replacement metadata histories.

With three voters, a majority is two, so one voter can be unavailable. With five, a majority is three, tolerating two. Those counts assume the remaining voters can communicate and satisfy the protocol; merely having enough running processes in disconnected network segments is insufficient.

The active controller coordinates broker registration/liveness, partition leadership and metadata changes. Broker data replication has its own replica and synchronization requirements. A healthy controller quorum does not prove every data partition has a safe leader, and losing metadata quorum does not mean every established data request instantly fails; metadata progress and recovery become constrained.

Spread voters across appropriate failure domains, monitor quorum replication and election behavior, and test voter loss and replacement procedures. Use the deployed version's supported quorum membership workflow. Stability comes from preserving consensus and recovery invariants, not from promising instantaneous, interruption-free elections.

KRaft roles and quorum operations, metadata disk recovery precautions