When a Kafka cluster has several brokers, they need a consistent answer to two questions: which brokers hold each partition, and which replica is its leader? The controller manages those assignments and changes them when a broker fails. This keeps partitions available without leaving each broker to make conflicting decisions. section 4.3.1 section 7.0
In a KRaft cluster, brokers can be configured for controller or broker roles. Controller-role nodes form a coordination cluster that elects one active controller; the others stand by. If the active controller fails, a standby can take over. One controller-broker is enough for local development but offers no controller failover. Three can tolerate one controller-broker failure; five can tolerate two. section 7.1
When a partition leader fails
Suppose a client is fetching messages when the broker leading its partition becomes unavailable. The controller detects the failure and triggers an election that promotes a replica. The client may briefly fail to fetch; it then requests updated metadata and connects to the new leader. Clients subsequently communicate with the responsible broker, not through the controller. section 7.4
The controller depends on cluster coordination, not a manually fixed leader. Older Kafka deployments used ZooKeeper to elect the controller and store metadata. KRaft integrates coordination into Kafka and uses the __cluster_metadata topic for cluster metadata, avoiding a separate ZooKeeper system. When planning a deployment, distinguish controller-role nodes from the single controller currently active. section 4.3.1 section 7.1
