Raft-Based Metadata Replication

An administrator changes a topic’s retention policy. The active controller records the change, but before Kafka can treat it as committed, other controllers must replicate it. Brokers then need to learn that the change is committed and apply the new policy.

Raft-based metadata replication connects those steps. It establishes an ordered history that survives supported controller failures and gives replicas a way to catch up or reconcile unfinished work after leadership changes.

We’ll follow a single metadata update through the log, then examine commitment, divergent replicas, and snapshots. The examples assume Kafka 4.x in KRaft mode with a stable voting set of Controllers 101, 102, and 103. Controller 101 is initially active, and broker-only processes follow metadata as non-voting observers.