Kafka Partition Leadership and the In-Sync Replica Set
Fast recall
Quick revision
Core answer
replica.lag.time.max.ms form the ISR (in-sync replicas). Producers with acks=all only get acknowledgment when every ISR member has the write, and min.insync.replicas is the durability floor — if the ISR shrinks below it, writes are rejected. Unclean leader election is disabled by default to prevent data loss when no in-sync replica is available.Whether you understand how Kafka achieves durability through replication, and how ISR membership controls the trade-off between availability and data safety
Thinking replication factor alone provides durability — `acks=all` without `min.insync.replicas >= 2` collapses to `acks=1` semantics when only the leader is in the ISR
Explain the unclean-leader-election trade-off, the role of `replica.lag.time.max.ms` (not message count) in ISR membership, and how a shrinking ISR causes silent durability loss
Interview-ready guide
Interview answer
A Kafka topic is split into partitions, and every partition has one leader broker and N followers. Producers and consumers only talk to the leader; followers exist to keep a copy of the log so the partition survives broker failure.
The ISR is the key concept:
- Not all followers are treated equally — at any moment a subset, including the leader, is the in-sync replica set
- A follower stays in the ISR as long as it fetches from the leader within
replica.lag.time.max.ms, default 30 seconds - It's time-based rather than message-based so that bursts of producer traffic don't kick healthy followers out of the ISR
`acks` and `min.insync.replicas` work together:
acks=allmeans the producer waits for every current ISR member to acknowledge- The trap is that if the ISR shrinks to just the leader,
acks=allsilently degrades toacks=1 min.insync.replicas=2on a replication-factor-3 topic prevents that — the broker rejects writes when fewer than two replicas are in the ISR, so the producer sees an exception and retries instead of losing data
Unclean leader election:
- When the leader fails and no in-sync replica is available, by default the partition stays offline until one comes back — no data is lost but writes pause
- Setting
unclean.leader.election.enable=truelets an out-of-sync replica become leader, which loses any messages it didn't have — only acceptable for logs and telemetry
My recommended baseline for any durability-sensitive topic is replication factor 3, min.insync.replicas=2, producer acks=all, and unclean leader election off — this survives one broker failure with no data loss and surfaces problems as exceptions rather than silent corruption.
Kafka Partition Leadership and the In-Sync Replica Set
Direct Answer
A Kafka topic is split into partitions; every partition has one leader broker and N follower replicas. Followers that have caught up within replica.lag.time.max.ms form the ISR (in-sync replicas). Producers with acks=all only get acknowledgment when every ISR member has the write, and min.insync.replicas is the durability floor — if the ISR shrinks below it, writes are rejected. Unclean leader election is disabled by default to prevent data loss when no in-sync replica is available.
Common Mistakes & Pitfalls
Thinking replication factor alone provides durability — acks=all without min.insync.replicas >= 2 collapses to acks=1 semantics when only the leader is in the ISR
Check your understanding
Answer these without looking back at the article.
- What's the difference between `acks=all` and `min.insync.replicas`?
- How does Kafka decide when to remove a follower from the ISR?
- When would you ever turn on `unclean.leader.election.enable`?
- What metrics indicate ISR shrink/expand churn in production?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.