Skip to content
LakeBench
ProblemsCommunityPricing
Sign inStart practicing
Back
  1. Home
  2. Interview prep
  3. min.insync.replicas with acks=all

Kafka · Internals

min.insync.replicas with acks=all

Mediumkafka-36
acks-allmin-insync-replicasdurabilityquorum

Question

How do acks=all and min.insync.replicas work together?

Solution

The producer setting acks=all instructs the broker to wait until every replica currently inside the in-sync replica (ISR) set confirms the write before returning success. However, acks=all only evaluates the current ISR size, meaning that if network partitions or crashes shrink the ISR down to just the leader, acks=all will silently succeed with only one copy on disk. Pairing acks=all with min.insync.replicas=2 forces the broker to reject writes with a NotEnoughReplicasException whenever the in-sync quorum drops below two, establishing true multi-node durability.

The silent durability trap of acks=all

A common misconception among junior engineers is assuming that acks=all guarantees data exists on all replicas defined by the topic replication factor. That is not how Kafka works. If a topic has a replication factor of 3, but two brokers undergo maintenance or fail health checks, Kafka shrinks the ISR list to the leader alone.

With only the leader in the ISR, an acks=all write succeeds the instant the leader writes to its own disk. If that single remaining broker crashes a second later, all messages written while the ISR was degraded are permanently lost.

Enforcing quorum with minimum in-sync replicas

The topic-level configuration min.insync.replicas sets the floor for write acceptance. When you configure min.insync.replicas=2 on a topic with replication factor 3:

  • If all 3 replicas are healthy, writes wait for all 3 and succeed.
  • If 1 follower fails, the ISR drops to 2 brokers (leader plus one follower). Since 2 meets the minimum, writes still succeed with acks=all.
  • If a second follower fails, leaving only the leader, the broker rejects incoming produce requests with NotEnoughReplicasException.

This setup prevents data loss by trading write availability for strict durability. Production pipelines handling critical streams like payment events or customer orders standardly combine replication factor 3, min.insync.replicas=2, and producer acks=all to survive any single broker loss without stalling or losing data.

PreviousNext