Skip to the page
Tecyfy

Kafka and streaming interview question · medium

What do acks=all and min.insync.replicas do together? A topic has 3 copies. Which settings lose no acknowledged message when a broker dies, and what happens to producers when 2 of the 3 brokers are down?

The short answeracks says how many copies must have a message before the producer is told it succeeded; min.insync.replicas says how few in-sync copies the broker will accept for an acks=all write.

The full answer

acks says how many copies must have a message before the producer is told it succeeded; min.insync.replicas says how few in-sync copies the broker will accept for an acks=all write. With 3 copies, the usual safe setting is acks=all and min.insync.replicas=2: every acknowledged message is on at least 2 brokers, so losing any one loses nothing, and the topic keeps taking writes while one broker is down. With 2 of 3 down, only 1 copy is in sync, fewer than 2, so producers get NotEnoughReplicas errors: Kafka refuses writes rather than accept ones it could lose.

1. The 3 acks settings

acksThe producer is told "done" whenRisk
0it has sent the recordLost with no error if the broker never got it
1the leader has written itLost if the leader dies before followers copy it
all (-1)every in-sync replica has itSafe while one in-sync replica survives

acks=all is the default in current clients, and the idempotent producer needs it.

2. Why acks=all alone is not enough

The in-sync replica set (ISR) shrinks when followers fall behind. If it shrinks to just the leader, acks=all means "the leader has it", the same as acks=1. min.insync.replicas puts a floor under that: with a floor of 2, a write that only the leader could take is refused.

3. The cases with 3 copies and a floor of 2

In-sync copiesacks=all writes
3Succeed, all 3 confirm
2 (one broker down, a rolling update)Succeed
1Fail with NotEnoughReplicas

AWS's MSK guidance is exactly this: 3 copies and min.insync.replicas of 2, because 1 copy takes partitions offline during an update and 2 copies can lose data.

4. What the producer should do when writes are refused

Retry with backoff within delivery.timeout.ms, and alert on the errors. Do not lower min.insync.replicas to 1 to get writes flowing: that trades an outage for silent data loss later.

5. Consumers see only safe messages

Whatever acks a producer used, a message is not visible to consumers until it is on all in-sync replicas and the floor is met, so a consumer never reads a message that a leader failure could take back.

What interviewers want: the 3 acks levels, the ISR shrinking, min.insync.replicas as the floor that makes acks=all mean something, replication 3 with a floor of 2 tolerating one broker down, and refusing writes over losing them.

Last updated 16 October 2026