How does replication factor and min.insync.replicas affect availability in Kafka?
Understand how Kafka replication factor and min.insync.replicas trade durability against availability, with the RF=3, ISR=2 pattern and interview questions.
Expected Interview Answer
Replication factor sets how many copies of each partition exist across brokers, while min.insync.replicas defines the minimum number of in-sync replicas that must acknowledge a write (with acks=all) for it to succeed; together they trade off durability against availability.
A partition has one leader and several followers; replicas that have caught up form the in-sync replica (ISR) set. With acks=all and min.insync.replicas=N, a produce request only succeeds while at least N replicas are in sync, otherwise the broker rejects writes with NotEnoughReplicas. A common durable setup is replication factor 3 with min.insync.replicas 2, which tolerates one broker failure while still accepting writes. Setting min.insync.replicas equal to the replication factor maximizes durability but means a single broker loss halts producing.
- Replication provides fault tolerance so a partition survives broker failure
- min.insync.replicas guarantees a write is on multiple replicas before acknowledgement
- RF=3 with min.insync.replicas=2 tolerates one failure and still accepts writes
- Prevents acknowledged data from being lost if the leader dies
- Lets you tune the durability-versus-availability balance per topic
AI Mentor Explanation
Replication factor is how many official scorers keep identical scorebooks; min.insync.replicas is the rule that a run only counts once at least two scorers have written it down together. With three scorers required-two, one can step away and play continues, but if only one remains you stop scoring to avoid a disputed total. More agreeing scorers means more safety at the cost of pausing when too few are present.
Step-by-Step Explanation
Step 1
Set the replication factor
Choose how many broker copies each partition has, commonly 3 for production durability.
Step 2
Understand the ISR
In-sync replicas are those caught up with the leader; the leader tracks this set.
Step 3
Configure min.insync.replicas
Set the minimum ISR count required to accept a write, typically 2 for RF=3.
Step 4
Produce with acks=all
The producer waits for all in-sync replicas to acknowledge, honoring min.insync.replicas.
Step 5
Handle failure
If ISR drops below the minimum, writes are rejected while reads continue, protecting durability.
What Interviewer Expects
- Clear distinction between replication factor and min.insync.replicas
- That min.insync.replicas only matters with acks=all
- The classic RF=3, min.insync.replicas=2 durable-yet-available configuration
- Understanding of the in-sync replica (ISR) set and leader election
- The trade-off: stricter settings raise durability but lower write availability
Common Mistakes
- Thinking min.insync.replicas has an effect with acks=1 or acks=0
- Setting min.insync.replicas equal to the replication factor and being surprised writes stop on one failure
- Confusing replication factor with partition count
- Assuming higher replication alone guarantees no acknowledged data loss without acks=all
Best Answer (HR Friendly)
“Replication factor is how many copies of the data Kafka keeps, and min.insync.replicas is how many of those copies must confirm a write before it counts. Tuning them lets you decide how much you value never losing data versus always being able to write.”
Code Example
# Create a topic with 3 copies of each partition
kafka-topics.sh --create --topic orders \
--bootstrap-server localhost:9092 \
--partitions 6 --replication-factor 3
# Require at least 2 in-sync replicas to accept writes
kafka-configs.sh --alter --topic orders \
--bootstrap-server localhost:9092 \
--add-config min.insync.replicas=2
# Producer must use acks=all for the setting to take effect
# acks=all + min.insync.replicas=2 => write needs 2 in-sync replicasFollow-up Questions
- Why does min.insync.replicas only matter when the producer uses acks=all?
- What error does a producer receive when the ISR falls below min.insync.replicas?
- What is unclean leader election and how does it affect durability?
- How would you configure a topic to tolerate two broker failures?
- What is the difference between the ISR set and the full replica set?
MCQ Practice
1. With replication factor 3 and min.insync.replicas 2, how many broker failures can occur while writes still succeed?
Two in-sync replicas are required, so losing one of the three brokers still leaves two and writes continue.
2. min.insync.replicas takes effect only when the producer uses which acks setting?
Only acks=all waits for the in-sync replicas, so min.insync.replicas is enforced with that setting.
3. What happens when the in-sync replica count drops below min.insync.replicas?
The broker rejects produce requests with NotEnoughReplicas, but consumers can still read existing data.
Flash Cards
What is replication factor? — The number of copies of each partition kept across brokers for fault tolerance.
What is min.insync.replicas? — The minimum in-sync replicas that must acknowledge an acks=all write for it to succeed.
Common durable config? — RF=3 with min.insync.replicas=2: tolerates one broker failure and still accepts writes.
What is the ISR? — The in-sync replica set: replicas fully caught up with the partition leader.