How do acks=all, min.insync.replicas, and replication.factor work together to define a durability guarantee?

## The three knobs **`replication.factor`** — a per-topic setting: how many copies (replicas) of each partition exist across brokers. With RF=3, each partition has one leader and two followers on three different brokers. This is the *ceiling* on how many copies can exist; it doesn't by itself force writes to reach all of them. **`min.insync.replicas`** (often abbreviated `min.insync.replicas` / `min.isr`) — a broker-default or per-topic setting: the minimum number of replicas in the **in-sync replica set (ISR)** that must acknowledge an `acks=all` write for it to be accepted. The ISR is the set of replicas currently caught up to the leader (within `replica.lag.time.max.ms`). **`acks`** — the producer setting (see related question). `min.insync.replicas` is **only consulted when `acks=all`**. Under `acks=1` or `acks=0` the broker ignores it entirely — a common trap. ## How they interact Under `acks=all`, when a producer sends a record the leader: 1. Checks the current ISR size. If `|ISR| < min.insync.replicas`, it **rejects** the write before appending with `NotEnoughReplicasException` (error code 19). 2. Otherwise it appends to its log and waits for the followers in the ISR to fetch and append. If the ISR shrinks below `min.insync.replicas` *after* the append but before full replication, it returns `NotEnoughReplicasAfterAppendException` (error code 20) — the record may be in the leader's log but is not considered committed. 3. Once all current ISR members have the record, the **high watermark** advances and the record is **committed** and acknowledged. ## The canonical recipe: RF=3, min.isr=2, acks=all - Each committed record is on **at least 2** brokers. - **Availability**: you can lose 1 broker and still produce (ISR=2 ≥ min.isr=2). - **Durability**: you can lose any 1 of the 2 ISR copies and still not lose an acknowledged record (1 ISR copy remains). - Lose 2 brokers and producing **halts** (ISR=1 < 2) — Kafka chooses consistency over availability here. This is intentional: it's better to reject writes than to silently accept un-replicated ones. ## Why not min.isr = RF? Setting `min.insync.replicas=3` with RF=3 means **any** single replica falling out of the ISR (even briefly, e.g. during a rolling restart or GC pause) blocks all producing. You get maximum durability but brittle availability. RF=3/min.isr=2 is the standard balance. ## Tradeoff summary | Setting | Durability | Availability for writes | |---|---|---| | min.isr = 1 | weak (acks=all ≈ acks=1) | high | | min.isr = 2 (RF=3) | strong | tolerates 1 failure | | min.isr = RF | strongest | brittle, no failure headroom | ## Edge cases - `min.insync.replicas` set higher than `replication.factor` makes the topic permanently un-writable under acks=all. - It does not affect consumers — they read up to the high watermark regardless. - It's enforced on the **current** ISR, so a recently-restarted follower not yet back in ISR doesn't count toward the minimum.