Kafka tolerates broker failure when three settings agree: a replication factor of 3, min.insync.replicas of 2, and producers using acks=all. Together they mean a write is acknowledged only after a majority of replicas hold it, so losing one broker neither loses data nor stops writes.
What does each setting control?
Replication factor is a topic setting: how many brokers keep a copy of each partition. One of the copies is the leader, and the rest follow it. The in-sync replicas, or ISR, are the copies that are keeping up.
The producer setting acks decides when a send counts as done. Apache Kafka's producer documentation lists four valid values: all, -1, 0 and 1. With acks=0 the producer does not wait for any acknowledgment. With acks=1 the leader writes locally and replies without waiting for followers. With acks=all, the leader waits for the full set of in-sync replicas. The documented default is all.
The topic setting min.insync.replicas sets the floor. It is the minimum number of in-sync replicas, including the leader, that must be present for a write to succeed when the producer uses acks=all. If the ISR shrinks below that number, the producer gets an exception instead of a silent downgrade. The default is 1.
Why is the default not enough?
Read the defaults together. A producer with acks=all sounds safe. But with min.insync.replicas at 1, a leader that is the only member of the ISR can acknowledge a write all by itself. If that broker then fails before followers catch up, the write is gone, even though the producer was told it succeeded.
Raising min.insync.replicas to 2 closes that gap. The Kafka documentation describes the typical durable setup as replication factor 3, minimum ISR 2 and acks=all, so a majority must persist each write.
What is the cost?
Availability. With three replicas and a minimum of 2, you can lose one broker and keep writing. Lose two and producers see errors until a replica recovers. That is the intended trade: refuse writes rather than accept ones that could vanish.
Constructed example: a three broker cluster takes one broker down for patching. The ISR for each partition drops to two, which still meets the minimum, so producers carry on. If a second broker fails during the same window, writes stop with an error. Your application must handle that error, by retrying with backoff or by buffering, and alert someone.
What about unclean leader election?
The topic setting unclean.leader.election.enable defaults to false. When true, a replica outside the ISR can become leader as a last resort, which the documentation says may cause data loss. Leave it off for data you cannot regenerate. Turn it on only for topics where availability beats completeness, such as a stream you can rebuild.
What should producers do about retries and duplicates?
The producer documentation lists enable.idempotence as true by default, and retries defaults to 2147483647, bounded in practice by delivery.timeout.ms, which defaults to 120000 milliseconds. Idempotence lets retries happen without writing duplicates to a partition. Do not lower retries to zero to hide errors. That pushes transient failures into your application code.
How to check or apply this
- Describe each critical topic and confirm replication factor is at least 3.
- Set
min.insync.replicasto 2 on those topics, not only as a broker default. - Confirm every producer uses
acks=alland has not overridden it. - Confirm
unclean.leader.election.enableis false on topics that carry business data. - Alert when the ISR for any partition falls below the minimum.
- Test it. Stop one broker in a staging cluster during a producer run and watch that nothing errors. Stop a second and confirm your application handles the failures.
Quick check
Does acks=all alone guarantee no data loss?
No. It waits for the in-sync replicas, but if the ISR contains only the leader, that is one copy. Pair it with a minimum ISR of 2.
What happens when the ISR falls below min.insync.replicas?
Producers using acks=all receive an exception and the write is rejected, rather than being accepted with fewer copies.
Sources
Last reviewed: 18 October 2026.
