Kafka acks, min.insync.replicas, and Producer Retries: The Durability Dial

Engineers love to ask "how durable is Kafka?" as if it were a single number. The honest answer is that Kafka has a durability dial, and most teams discover its position only after losing data. Three settings make up the dial: producer acks, broker min.insync.replicas, and whether the producer retries with idempotence on.

Start with acks. This is the producer's contract with the leader.

acks=0 means fire and forget. The producer hands the record to the socket and considers it done. The leader may never see it. The network may drop it. This is fine for metric scrapes that you can afford to lose. It is not fine for orders.

acks=1 means the leader writes to its local log and confirms. Followers have not seen the record yet. If the leader crashes in the next millisecond, that record is gone, and a new leader from the in-sync replica set will not have it. People assume acks=1 plus replication factor 3 is safe. It is not. Replication factor only matters once a write has been replicated.

acks=all means the leader waits until every member of the in-sync replica set has appended the record. Only then does it advance the High Watermark and acknowledge the producer. Now the write survives the loss of the leader, because at least one follower in the ISR has it.

But acks=all alone is still a trap. If your ISR has shrunk to a single broker (the leader itself), then acks=all waits for one broker. You wrote to one machine and called it durable. That is where min.insync.replicas enters. Set it to 2, and the broker rejects writes whenever the ISR drops below two members. Producers fail loudly instead of silently writing to a single replica. Loud failure is the goal.

Now retries. With acks=all, the producer waits for the broker. If the broker times out, the producer retries. Without idempotence, a retry can write the same record twice. Set enable.idempotence=true, and the producer attaches a sequence number that the broker uses to deduplicate. You get exactly-once writes to a single partition without paying for transactions.

The production failure mode worth memorizing: a slow follower gets booted from the ISR, the ISR drops to one, min.insync.replicas=2 is not set, and acks=all quietly becomes acks=1 until the operator notices. The producer is still waiting for "all in-sync replicas." The in-sync set just happens to be one broker, the leader, the very machine whose failure you are trying to survive. Three replicas on paper. One on disk. Set both knobs, or do not pretend you have durability.

The honest mental model. acks controls who must confirm. min.insync.replicas controls how many must even exist. Idempotent retries control whether retry creates duplicates. Pick the combination for the workload, not for the dashboard.