In Kafka, we have two kinds of replicas:

Leader replica: All requests from consumers and producers are routed through the leader replica for a partition. Each partition has one broker designated as the leader replica.

Follower replica: All replicas that aren’t the leader are called follower replicas. They don’t participate in servicing consumer or producer requests. Their only task is to replicate messages from the leader replica and stay up to date with the latest messages the leader has. If the leader replica fails, one of the follower replicas is promoted to be the leader.

The follower replicas send fetch requests for the latest messages to the leader replica, similar to how other clients interact with the leader. The leader replica knows how far behind a follower replica is by examining the offset in the fetch request sent by the follower replica. The offset denotes the next message the follower replica wants to consume. If a replica hasn’t requested a message in the last 10 seconds or if the replica has requested messages in the last 10 seconds but has failed to catch up to the most recent messages, then that follower replica is considered an out of sync replica. This means they will not be considered for the election of the leader should the current leader fail. This makes sense since the out of sync replica doesn’t have the latest messages and thus shouldn’t be promoted as the leader. The amount of time a follower can be inactive or behind before it is considered out of sync is controlled by the replica.lag.time.max.ms configuration parameter. Tweaking this configuration has implications on client behavior and data retention during leader election. Conversely, the follower replicas that are requesting the latest messages from the leader replica are thought to be in-sync replicas. Only these replicas are eligible to run for the leader election.

There’s also the concept of a preferred leader. This is the broker that was chosen to be the leader replica when the topic was initially created. The reason the preferred broker exists is because, at the time of the topic creation, the algorithm attempts to evenly divide the partition leaders among the available brokers. If all the replica leaders for all the partitions in a cluster are in fact the preferred leaders, then the load will be evenly divided amongst the brokers. If the configuration auto.leader.rebalance.enable is set to true, then Kafka will trigger an election to make the preferred leader as the leader replica if it isn’t already so. However, the preferred leader has to meet the criterion of being an in-sync replica.