Leaders & Followers
IntermediateEvery partition has one leader that handles all reads and writes; followers replicate from the leader and can be promoted to leader if the leader fails.
Overview
For every Kafka partition, one broker is designated the leader and all others holding replicas are followers. All producer writes and consumer reads go through the leader — followers exist solely for redundancy. A follower is "in-sync" (ISR) when it has replicated all messages within the window defined by replica.lag.time.max.ms. If the leader fails, the controller elects a new leader from the ISR, maintaining data safety. Understanding leader distribution is critical for balancing load across a Kafka cluster.
Leader Election & ISR
The controller broker (or KRaft quorum) tracks which brokers are alive and manages leader elections. When a leader fails, the controller picks the first ISR member and promotes it. Only ISR members are candidates — unclean.leader.election.enable=false (the safe default) prevents out-of-sync replicas from becoming leader.
# Inspect leader and ISR per partition
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders
# Sample output:
# Topic: orders Partitions: 3 ReplicationFactor: 3
# Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
# Partition: 1 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
# Partition: 2 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
#
# Ideal: leaders evenly spread across brokers (1 per partition)
# Problem: if broker 1 is slow, ISR may shrink:
# Isr: 1 ← only leader is in-sync, followers fell behind
# Trigger preferred leader election (restores original leader distribution)
kafka-leader-election.sh \
--bootstrap-server localhost:9092 \
--election-type PREFERRED \
--all-topic-partitionsReplication Lag & Durability Settings
replica.lag.time.max.ms (default 30 s) defines how far behind a follower can fall before being removed from the ISR. Combined with acks=all and min.insync.replicas, this determines the durability guarantee.
# Broker config — replica lag threshold
replica.lag.time.max.ms=30000 # follower removed from ISR if > 30 s behind
# Producer durability contract
# acks=all → leader waits for ALL ISR members to confirm write
# acks=1 → only leader confirms (default — may lose data on leader crash)
# acks=0 → fire-and-forget (fastest, no guarantee)
# application.properties
spring.kafka.producer.acks=all
spring.kafka.producer.properties.enable.idempotence=true
spring.kafka.producer.properties.min.insync.replicas=2
# What this guarantees:
# - With RF=3 and min.insync.replicas=2:
# cluster can lose 1 broker and still accept writes
# - If only 1 ISR member remains: produce throws NotEnoughReplicasException
# → prevents silent data loss
# Monitor ISR shrinkage via JMX or Prometheus
# kafka.server:type=ReplicaManager,name=IsrShrinksPerSec ← should be ~0Follower Fetch & Read Scalability
Followers fetch messages from the leader using the same FetchRequest protocol as consumers. In Kafka 2.4+ (KIP-392) consumers can optionally fetch from the nearest replica for lower latency in multi-AZ deployments — this is "follower reads".
# KIP-392: Follower reads (rack-aware consumer routing — Kafka 2.4+)
# Broker config — assign broker to AZ/rack
broker.rack=us-east-1a # on broker 1
broker.rack=us-east-1b # on broker 2
broker.rack=us-east-1c # on broker 3
# Consumer config — prefer replica in same AZ
spring.kafka.consumer.properties.client.rack=us-east-1a
# Kafka will route fetches to the nearest in-sync replica in the same rack
# → reduces cross-AZ data transfer costs and latency
# Replica.selector.class (broker side — default: LeaderEpochOrLeaderReplica)
replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelector
# Verify consumer is using a follower
kafka-consumer-groups.sh \
--bootstrap-server localhost:9092 \
--describe --group my-group
# HOST column shows which broker each partition is fetched fromKey Points to Remember
- 1Every partition has exactly one leader; all produces and consumes go through the leader.
- 2Followers replicate from the leader; ISR members have replicated all messages within lag threshold.
- 3On leader failure, the controller promotes the first ISR member as the new leader.
- 4unclean.leader.election.enable=false (default) prevents data loss by rejecting out-of-sync leaders.
- 5acks=all + min.insync.replicas=2 guarantees writes survive one broker failure.
- 6KIP-392 (Kafka 2.4+) enables consumer reads from the nearest rack-aware replica.
Interview Questions
Sign in to ask AriaWhat is the difference between a leader and a follower replica in Kafka?
What is the ISR and what happens when a follower falls out of the ISR?
What is unclean leader election and why is it dangerous?
How do acks=all and min.insync.replicas work together to guarantee durability?
How does Kafka balance partition leaders across brokers and how do you rebalance manually?
Ask Aria about Leaders & Followers
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.