Kafka ISR Failure Simulator

Durability, availability, and what "in sync" really means

Kafka gives you a three-way tradeoff, not a free lunch: durability (survive a broker failure without losing acknowledged writes), availability (keep accepting writes during a failure), and how strict you are about what counts as "in sync." You cannot maximize all three at once.

• acks=all means "wait for every replica currently in the ISR" — not "wait for all 3 replicas." If followers have fallen out of the ISR and only the leader remains, with min.insync.replicas=1, acks=all acknowledges after just the leader writes — exactly as durable as acks=1 in that moment, even though the topic config looks strict.
• min.insync.replicas is the floor: if the ISR shrinks below it, the leader rejects writes with NotEnoughReplicas (or NotEnoughReplicasAfterAppend) rather than silently accepting them with weaker durability.
• When the leader fails, Kafka elects a new leader from the remaining ISR members — safe, no acknowledged data is lost, because every ISR member had every acknowledged record. If the ISR is empty and unclean.leader.election.enable=true, an out-of-ISR (lagging) replica can become leader — the partition stays available, but any records the old leader had that never replicated are gone silently. If ISR is empty and unclean election is disallowed, the partition goes offline: unavailable, but no silent data loss.
• This model fixes one partition and one produce request; it does not simulate replication lag dynamics, controller failover time, or `min.insync.replicas` interacting with multiple partitions. See Kafka replication for the full ISR and controller mechanics.