Overview
KIP-500 states what KRaft is meant to improve. It aims to manage metadata in a more scalable and robust way, with support for more partitions, and brokers should be able to start quickly even with hundreds of thousands or millions of partitions. Because standby controllers already hold the latest metadata, a controller failover does not need a lengthy reload. Brokers also pull changes from the metadata log instead of the controller pushing each one, so metadata changes arrive in the same order everywhere and brokers avoid ending up in a divergent state. These are the KIP's goals: the Apache documentation publishes no benchmark figures for partition counts or failover times, so measure them on your own cluster.
Production tip
Check yourself
In KRaft, how do brokers receive metadata changes?
Sources
- KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum (opens in a new tab)
- KRaft operations (4.2 documentation) (opens in a new tab)
- KIP-631: The Quorum-based Kafka Controller (opens in a new tab)
Checked against Kafka 4.2 documentation on Oct 2026. Draft: not yet reviewed by a Kafka specialist. Releases move on, so confirm against the current documentation before you act on a number.