What does min.insync.replicas control in Kafka?
`min.insync.replicas` (commonly abbreviated `min.isr`) is a broker/topic-level configuration that specifies the minimum number of replicas that must be in the ISR for a produce request with `acks=all` to be accepted. If the current ISR falls below this threshold, the broker rejects produce requests with a `NotEnoughReplicasException`, effectively halting writes rather than accepting messages that could be lost.
The canonical safe configuration for a 3-broker cluster is `replication.factor=3` with `min.insync.replicas=2`. This means you can tolerate one broker failure and still accept writes — the remaining 2 replicas satisfy the minimum. Setting `min.insync.replicas=3` requires all three replicas to be in sync, meaning any single broker failure stops writes entirely. Setting it to 1 provides no durability benefit over `acks=1`.
This setting only takes effect when the producer uses `acks=all`. With `acks=1` or `acks=0`, the broker ignores `min.insync.replicas` entirely — a common source of confusion. The setting is purely a server-side guard for the strongest producer acknowledgment mode.
The trade-off is availability versus durability: a lower `min.insync.replicas` keeps writes flowing under degraded conditions but risks data loss if the leader fails before lagging replicas catch up. A higher value maximizes durability but reduces the failure tolerance window. In practice, `replication.factor=3, min.insync.replicas=2, acks=all` is the industry-standard baseline for durable Kafka deployments, giving you a one-failure tolerance with no data loss.
The setting can be configured at the broker level (`min.insync.replicas` in `server.properties`) as a default, and overridden per-topic via `kafka-configs.sh`, allowing you to apply stricter durability to critical topics without impacting higher-throughput, lower-durability topics.
Correctly explains that min.insync.replicas sets the floor on ISR size for acks=all writes, and knows that writes are rejected below this threshold rather than acknowledged with reduced durability.
Gives the canonical 3/2 example with reasoning, clarifies that the setting is a no-op with acks=0 or acks=1, and articulates the availability vs. durability trade-off. Mentions per-topic override capability.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment