How does Kafka's KRaft controller quorum manage cluster metadata?

A small set of dedicated controller nodes (an odd number, commonly 3 or 5, for clean majority voting) forms a Raft consensus group that maintains the cluster's metadata — topic configs, partition assignments, current leaders, ACLs — as a replicated, append-only log, rather than each broker independently tracking its own view.

process.roles=controller
node.id=1
controller.quorum.voters=1@host1:9093,2@host2:9093,3@host3:9093

One controller in the quorum is elected the active controller and is the only one that processes metadata changes at a time; the others replicate its log and stand ready to take over if it fails. Brokers (which may or may not also serve as controllers, depending on cluster size) subscribe to this metadata log and apply changes locally, which is how every broker in the cluster stays in agreement about partition leadership and topic configuration without a central external lookup on every request. This design is what let Kafka 4.0 remove the external coordination system entirely — metadata consensus is now handled natively, inside Kafka's own replicated log mechanism.