liveBook · Manning

Follower controller

As explained in Kafka for Architects

A follower controller is a KRaft controller that replicates metadata from the active controller and participates in controller quorum decisions.

A follower controller is a KRaft controller that keeps a replicated view of the metadata log while supporting controller-quorum decisions. It periodically fetches metadata from the leader controller; each fetch both advances replication and confirms that the leader remains reachable. section 9.1.3

During leader failure, a follower controller participates in recovery:

  • If no fetch response arrives before controller.quorum.fetch.timeout.ms, it transitions to the candidate state. section 9.1.3
  • It requests votes from other controllers, which compare its replicated metadata log with their own. section 9.1.3
  • After winning a majority, the new leader verifies committed entries, fetches missing entries, and only then serves metadata requests. section 9.1.3

How Kafka for Architects covers it

How deep it goes
Explains fetch-based heartbeats, election participation, log comparison, and post-election synchronization without detailing follower-failure handling.
Examples
Uses a leader-controller failure scenario involving fetch timeouts, vote requests, log synchronization, and broker reconnection.
What it assumes
Assumes familiarity with KRaft controllers, metadata logs, controller quorum, and leader-election terminology.
What you can do after
Evaluate controller failover by tracing follower fetches, election conditions, metadata synchronization, and broker recovery.
How it connects
Connects metadata logs with leader election, candidate state, controller quorum, and broker leader discovery.
Cover of Kafka for Architects
liveBookmanning.com
Read Kafka for Architects on liveBook Get the book at manning.com

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kafka for Architects. The section links point to the parts of the book it draws on.