Replication, ISR & Durability

Lesson 5 said at-least-once “never loses data” — but why doesn’t it? Because Kafka replicates every partition across multiple brokers, so a broker failure doesn’t take your data with it. Replication is what makes Kafka durable and highly available, and the settings that control it — acks and min.insync.replicas — are the most important durability decisions you’ll make. This lesson makes them concrete, with a measured durability table.

Leaders, followers, and the replication factor

Every partition is stored on multiple brokers, set by the replication factor (RF). With RF=3, each partition lives on 3 brokers:

• One leader per partition. For each partition, one of its replicas is the leader — it handles all reads and writes for that partition. (Leadership is spread across brokers so every broker leads some partitions; no single broker is a bottleneck.)
• Followers replicate. The other replicas are followers: they continuously fetch new messages from the leader to stay current. They don’t serve clients; their job is to be ready to take over.
• Failover. If the leader’s broker dies, Kafka promotes one of the up-to-date followers to leader — automatically, in milliseconds — and clients reconnect to the new leader. The partition stays available, and no acknowledged data is lost (given the right settings below).

The replication factor is the durability floor: RF=3 means a partition survives losing up to 2 of its 3 brokers for reads. RF=1 (no replication) means a single broker failure loses that partition’s data permanently — never use RF=1 for data you care about. RF=3 is the standard production choice.

ISR: in-sync replicas

Not all followers are necessarily caught up — a slow or briefly-disconnected follower falls behind. The in-sync replicas (ISR) are the replicas (leader + followers) that are currently caught up with the leader. This set is dynamic: a follower that lags too far drops out of the ISR, and rejoins once it catches up.

The ISR is central to durability because a write is considered “committed” only once all members of the ISR have it. Committed messages are the ones Kafka promises not to lose — and only a replica in the ISR can be promoted to leader. So the ISR is the set of replicas that could safely take over without losing committed data. This is where the durability settings come in: they control how many replicas must be in the ISR and acknowledge a write before you treat it as done.

The durability dials: acks + min.insync.replicas

Durability is set by two settings working together — acks on the producer (Lesson 3) and min.insync.replicas on the topic/broker. Here’s exactly what each combination gives you on RF=3 (measured as a decision table):

setting	waits for	guarantee
acks=0	nothing	fastest; can lose data silently (fire-and-forget)
acks=1	leader only	loses data if the leader crashes before followers replicate
acks=all + min.insync.replicas=2	leader + 1 in-sync follower	no data loss while ≤1 broker fails — the safe default

The logic of the safe default: with acks=all, a write is acknowledged only once all in-sync replicas have it; with min.insync.replicas=2, the broker refuses writes unless at least 2 replicas are in-sync. Together on RF=3, every acknowledged write is on at least 2 brokers, so losing any single broker loses no acknowledged data, and reads survive up to 2 broker failures. That’s durable and available.

Why 2 and not 1 or 3?

• min.insync.replicas=1 means a write can be acknowledged with only the leader having it. If that leader then crashes before a follower replicates, the write is gone — you’ve reintroduced the acks=1 data-loss window. Too risky.
• min.insync.replicas=3 (= RF) means every replica must be in-sync to accept a write. Now if any one broker is down or lagging, the partition rejects all writes — you’ve traded availability for a tiny durability gain. Too strict.
• min.insync.replicas=2 is the sweet spot: writes need 2 copies (durable), and the cluster keeps accepting writes even with 1 broker down (available). This is the standard production setting.

The key insight: durability is not free and not automatic. It’s a deliberate combination of RF (how many copies exist), acks (how many must confirm), and min.insync.replicas (how many must be in-sync to accept the write). The standard, safe production setup is RF=3, acks=all, min.insync.replicas=2 — memorise it. Lower settings buy a little latency at the cost of a data-loss window you probably don’t want.

With replication understood, the next lesson looks at where all this replicated data actually lives and how long it stays: storage, retention and compaction.

Pitfalls to Avoid

1. RF=1 for data you care about. No replication means one broker failure loses the partition permanently. Use RF=3 in production; RF=1 only for truly disposable data.
2. acks=1 with important data. The leader can crash before followers replicate, silently losing acknowledged writes. Use acks=all.
3. acks=all but min.insync.replicas=1. This quietly reintroduces the acks=1 loss window — a write can commit with only the leader. Set min.insync.replicas=2 on RF=3.
4. min.insync.replicas=3 on RF=3. Any single broker down or lagging halts all writes to the partition. You lose availability for negligible durability gain. Use 2.
5. Forgetting durability is a combination. RF alone, or acks alone, isn’t enough — it’s RF + acks + min.insync.replicas together. The safe trio is 3 / all / 2.
6. Ignoring under-replicated partitions. When ISR < RF, you’ve lost redundancy and are one failure from trouble. Alert on under-replicated partitions (Lesson 11) and fix them promptly.

Quick Recap

• Every partition is replicated across RF brokers: one leader (all reads/writes) + followers that replicate it. If the leader dies, an in-sync follower is promoted automatically. Use RF=3.
• ISR (in-sync replicas) = replicas currently caught up. A write is committed once all ISR have it, and only ISR members can become leader — so ISR is the durability-critical set.
• Durability = acks + min.insync.replicas (on RF). Measured table: acks=0 lossy; acks=1 loses on leader crash; acks=all + min.insync.replicas=2 loses no acknowledged data while ≤1 broker fails — the safe default.
• min.isr=1 risks loss; min.isr=3 kills availability on any broker loss; 2 is durable and available. The standard: RF=3, acks=all, min.insync.replicas=2.

Next lesson: where the replicated data lives and how long — storage, retention and compaction, with disk-sizing arithmetic.