A quick refresher on the pieces that this setting protects.

Apache Kafka is a platform for storing and moving streams of events. An event is a small record of something that happened, such as a payment, a click, or a sensor reading. Kafka keeps these events on disk, in order, so that many applications can read them later.

Why data safety is a real question

Kafka runs on ordinary servers, and ordinary servers fail. Disks break, machines lose power, networks drop, and software crashes. If each partition lived on exactly one broker, then any failure of that broker would make the data unavailable, or lose it entirely. Kafka’s answer is replication: keeping several copies of each partition on different brokers. But copies alone are not enough. We also need rules about when a write counts as safely stored, and that is where min.insync.replicas enters the story.

To understand the setting, first understand how Kafka copies data.

Each partition has a number of copies, called replicas. The number of copies is set by the replication factor. A replication factor of three means every partition exists on three different brokers. One of those replicas is chosen as the leader, and the others are followers.

flowchart LR
  P[Producer] --> L[Leader replica on Broker 1]
  L --> F1[Follower replica on Broker 2]
  L --> F2[Follower replica on Broker 3]
  C[Consumer] --> L
        

How followers copy data

Followers work like consumers. They repeatedly ask the leader, “Do you have anything new for me?” The leader sends the latest records, and the follower appends them to its own log and asks again. This means followers are always slightly behind the leader, by a tiny amount if everything is healthy, and by a lot if the follower is slow or disconnected.

What happens when a leader fails

If the broker holding the leader dies, Kafka promotes one of the followers to become the new leader, and producers and consumers continue with it. This is why replication provides high availability. But there is a catch: a follower that was far behind at the moment of failure does not have all the data. Promoting such a follower could silently lose records that the old leader had accepted. Kafka needs a way to know which followers are safe to promote, and that leads us to the next idea.

The “ISR” is the list of replicas that are caught up and trusted.

For every partition, Kafka maintains a set called the in-sync replicas, or ISR. It always contains the leader, and it also contains every follower that is sufficiently caught up with the leader. Only members of this set are considered safe to take over as leader, and only members of this set count when we ask “is this write safely stored?”

What does “in sync” mean?

A follower is in sync if it has recently kept up with the leader. More precisely, the follower must have contacted the leader and caught up to its latest data within a time limit set by the broker setting replica.lag.time.max.ms, which by default is thirty seconds. If a follower goes silent or falls too far behind for longer than that, the leader removes it from the ISR. When the follower recovers and catches up again, it is added back.

sequenceDiagram
  participant L as Leader
  participant F1 as Follower 1
  participant F2 as Follower 2
  L->>F1: New records
  F1-->>L: Fetch again, caught up
  L->>F2: New records
  Note over F2: Follower 2 stalls, disk is slow
  L->>L: No catch up within the time limit
  L->>L: Remove Follower 2 from the ISR
  F2-->>L: Later, catches up again
  L->>L: Add Follower 2 back to the ISR
        

The definition in one sentence, followed by what it really means.

The setting min.insync.replicas defines the minimum size the ISR must have for Kafka to accept writes that demand full acknowledgement. The count includes the leader itself. So a value of two means the leader plus at least one follower must be in sync.

The two jobs it does

The setting only makes sense alongside the producer’s acks choice.

When a producer sends a record, it chooses how much confirmation it wants back from Kafka. This choice is called acks, short for acknowledgements, and it has three levels.

What acks all really waits for

Here is a subtle point that surprises many people. With acks set to all, the leader waits until every replica currently in the ISR has copied the record, not merely until the minimum number of replicas has. The minimum acts as a gate before this happens: if the ISR is smaller than the minimum, the leader rejects the write immediately. If the ISR is at least the minimum, the leader accepts the write and waits for all current ISR members.

sequenceDiagram
  participant P as Producer with acks all
  participant L as Leader
  participant F1 as Follower 1
  participant F2 as Follower 2
  P->>L: Send record
  L->>L: Is the ISR size at least the minimum
  L->>L: Append record to the leader log
  L->>F1: Replicate
  L->>F2: Replicate
  F1-->>L: Copied
  F2-->>L: Copied
  L-->>P: Acknowledge success
        

The moment the safety net tightens is the moment producers notice it.

Suppose a topic has a replication factor of three and a minimum of two. Normally the ISR has three members. If one broker fails, the ISR shrinks to two, which still meets the minimum, so everything continues. If a second broker fails or falls behind, the ISR shrinks to one, which is below the minimum. From that moment, the leader refuses writes that demand full acknowledgement.

flowchart TD
  A[Producer sends with acks all] --> B{Is ISR size at least the minimum}
  B -->|Yes| C[Leader appends and waits for the ISR]
  C --> D[Success returned to producer]
  B -->|No| E[Leader rejects the write]
  E --> F[Producer receives a not enough replicas error]
  F --> G[Producer retries until it succeeds or times out]
        

The two error types

Both errors are retriable, which means a well-configured producer automatically tries again for a while. If the problem clears quickly, for example a follower catches up within seconds, the retry succeeds and the application never notices. If the problem persists longer than the producer’s delivery timeout, the send finally fails and the application receives an error.

What still works

It is important to understand that reads keep working. Consumers can continue reading everything that was already safely committed, because the minimum only restricts new acknowledged writes. Producers using weaker acks values also keep writing, though without protection. Only the combination of acks set to all and a too-small ISR is blocked.

Durability and availability come from how these three settings fit together.

Two simple formulas

With acks set to all, two easy rules describe the behaviour, assuming all replicas are healthy at the start.

There is no universal answer, but there is a sensible default and a clear way of thinking.

The classic recommendation

For most production topics that carry important data, the widely used combination is a replication factor of three, a minimum of two, and producers using acks of all. This lets the cluster survive the loss of one broker without losing acknowledged data and without stopping writers, and it still refuses writes when only one healthy copy remains.

flowchart TD
  A[How valuable is the data] --> B{Can you afford to lose some records}
  B -->|Yes, logs or metrics| C[Replication factor 2 or 3 with minimum 1]
  B -->|No, business events| D{Must writes survive one broker outage}
  D -->|Yes| E[Replication factor 3 with minimum 2]
  D -->|Writes may stop during outages| F[Replication factor 3 with minimum 3 or 2 on 2]
  E --> G{Must data survive two simultaneous failures}
  G -->|Yes| H[Replication factor 5 with minimum 3]
  G -->|No| I[Keep replication factor 3 with minimum 2]
        

Questions to ask yourself

A sister setting decides what happens when even the ISR is gone.

Sometimes failures are so bad that every replica in the ISR is lost, and only out-of-sync followers remain, holding an incomplete copy of the data. Kafka must choose between two unpleasant options: make the partition unavailable until an in-sync replica returns, or promote an out-of-sync replica and accept that some acknowledged records will be lost. The broker setting unclean.leader.election.enable controls this choice.

How the two settings complement each other

Think of the minimum as guarding the front door, controlling when writes are accepted, and unclean leader election as guarding the back door, controlling who may take over after a disaster. For strong durability you need both closed: a sensible minimum together with unclean election disabled. Leaving unclean election on makes the minimum’s protection partially pointless, since a lagging replica may become leader and overwrite the true history.

flowchart LR
  A[Leader and ISR members fail] --> B{Unclean election allowed}
  B -->|No| C[Partition offline until an ISR member returns]
  B -->|Yes| D[Out of sync replica becomes leader]
  C --> E[No acknowledged data lost, temporary downtime]
  D --> F[Service returns fast, some acknowledged data lost]
        

Reading has its own safety rule, and it works hand in hand with the ISR.

Kafka does not let consumers read every record the leader has appended. It only exposes records up to a marker called the high watermark, which is the highest offset that has been copied to all replicas currently in the ISR. A record beyond the high watermark exists on the leader but is not yet considered committed, so consumers cannot see it yet.

flowchart LR
  A[Records 0 to 7 on all ISR members] --> B[High watermark]
  B --> C[Records 8 to 10 only on the leader]
  A --> D[Visible to consumers]
  C --> E[Not visible yet]
        

Why this matters

This rule guarantees that consumers never see a record that could vanish after a leader change. Suppose consumers could read records held only by the leader, and then the leader crashed. A new leader would not have those records, and consumers would have seen data that never officially existed. The high watermark prevents this.

The relationship with the minimum

When the ISR shrinks, the high watermark is calculated over fewer replicas, so it can advance even though a lagging follower has been removed. The minimum then ensures that this smaller group is still large enough to be meaningful. Without a minimum, the high watermark could advance based on the leader alone, meaning “committed” would merely mean “written on one machine”.

Understanding the causes helps you prevent a great many not-enough-replicas alarms.

Flapping: the sneaky pattern

Sometimes a follower keeps dropping out and rejoining, over and over. This pattern, called ISR flapping, produces intermittent not-enough-replicas errors that appear and disappear in minutes and are notoriously hard to catch. It usually points to a borderline resource problem such as a busy disk or a saturated network link on one broker, not to a dramatic failure. Watching the rate of ISR shrinks and expansions is the best way to spot it.

Let us watch what happens with a replication factor of three and a minimum of two.

flowchart LR
  S1[ISR of 3 all healthy] -->|one broker fails| S2[ISR of 2 writes continue]
  S2 -->|second broker fails| S3[ISR of 1 writes rejected reads continue]
  S3 -->|one broker returns and catches up| S2
  S2 -->|other broker returns| S1
        

A scenario that goes wrong when the minimum is one

Now consider the same setup, but with the minimum left at the default of one. Two followers fall behind because of a network problem, and the ISR quietly shrinks to just the leader. Producers with acks of all keep getting “success”, because the leader alone satisfies the rule. Then the leader’s disk fails. The followers have not seen the last several minutes of data, and if unclean election is on they may take over, or if it is off the partition stays offline. In either case, records that were acknowledged as safe are gone or trapped.

Planned work is where careless settings hurt the most.

Rolling restarts

Upgrading or patching a Kafka cluster means restarting brokers one at a time. With a replication factor of three and a minimum of two, restarting a single broker temporarily reduces the ISR of affected partitions to two, which is still acceptable. The essential rule is to restart only one broker at a time, and to wait until it has fully caught up and rejoined the ISR of all its partitions before moving to the next. Restarting a second broker too early would drop some partitions below the minimum and stall producers.

Spreading replicas across zones

Replicas of the same partition should live in different failure domains, such as separate racks or cloud availability zones. Kafka supports this through rack awareness, where each broker is labelled with its location, and replica placement spreads copies across locations. With a replication factor of three and three zones, each zone holds one copy, and a minimum of two means the loss of an entire zone leaves writes running.

flowchart TD
  P[Partition with 3 replicas]
  P --> Z1[Zone A holds replica 1]
  P --> Z2[Zone B holds replica 2]
  P --> Z3[Zone C holds replica 3]
  Z1 --> R[Minimum of 2 means one whole zone can fail and writes continue]
  Z2 --> R
  Z3 --> R
        

Knowing where the value lives prevents unpleasant surprises.

Practical guidance

Set a sensible broker default, such as two on a cluster where topics normally have a replication factor of three, so that newly created topics are protected automatically. Then override it at topic level when a particular topic has different needs. The topic-level value can be changed on a live topic without restarting brokers, but changing it takes effect immediately, so plan it as you would any production change.

Internal topics

Kafka keeps some internal topics for its own operation, such as the topic that stores consumer group offsets and the topic that stores transaction state. These have their own replication and minimum settings, controlled by broker configuration. The transaction state log, for example, has its own minimum with a default of two. If internal topics have weak settings, then the reliability of offsets and transactions is weak no matter how carefully your data topics are configured, so check them in every new cluster, especially small development-style clusters that are later promoted to production.

Governance

Because the minimum is a server-side value, anyone with permission to alter topic configurations can weaken it, for example dropping it from two to one to silence errors during an incident, and forgetting to restore it. Restrict who may alter topic settings, review changes, and keep topic configurations in version-controlled definitions so that drift is visible.

Does a higher minimum make Kafka slower? The answer is more nuanced than most people expect.

The minimum itself is only a check, and it costs almost nothing. What costs time is the acknowledgement level. With acks of all, the leader waits for every replica in the ISR to copy the record, so the write is as slow as the slowest in-sync follower. Raising the minimum does not add waiting by itself, because the leader was already waiting for all ISR members. But designing for more copies, for instance a replication factor of five, means more followers to wait for, and more network and disk traffic.

Slow followers slow everyone

Because acks of all waits for every current ISR member, one slow but not-yet-removed follower slows every write to that partition until the lag limit removes it. This is why healthy disks and stable networks on all brokers matter, and why tuning the lag limit is a balance. A short limit removes slow followers quickly but risks flapping. A long limit tolerates hiccups but lets slow followers drag out latency.

When writes are rejected, producers retry. Retrying safely needs a few extra ideas.

When the ISR falls below the minimum, a producer receives a retriable error. Kafka producers retry automatically for as long as their delivery timeout allows, which by default is two minutes. During this time the application usually sees only a delay, not an error, and if the ISR recovers quickly the write goes through.

The duplicate problem

Retries can create duplicates. Recall the error that means the record was appended to the leader but the ISR shrank before acknowledgements arrived. The producer is told the write failed and sends it again, yet the first copy may already exist in the log. Without protection, the partition now contains the record twice.

sequenceDiagram
  participant P as Producer
  participant L as Leader
  P->>L: Send record 42
  L->>L: Append record 42
  L->>L: ISR shrinks below the minimum
  L-->>P: Error, not enough replicas after append
  P->>L: Retry record 42
  L->>L: Detect the same sequence number if idempotence is on
  L-->>P: Acknowledge without a second copy
        

The idempotent producer

Enabling idempotence gives every producer an identity and every record a sequence number per partition. The broker uses these to recognise a retried record it has already stored, and discards the duplicate while still acknowledging success. Recent Kafka clients enable this by default, and it requires acks of all, which fits perfectly with the minimum in-sync replica design.

The whole design only pays off if you notice the ISR shrinking before it becomes a crisis.

Alert design that works

A few habits protect your data, and a few quietly endanger it.

Helpful patterns

Anti-patterns to avoid

Different kinds of data justify different combinations of settings.

Let us follow a realistic incident from first alarm to lasting fix.

A ride-booking company runs a “bookings” topic with a replication factor of three and a minimum of two. At peak hour, the booking service starts logging errors saying there are not enough replicas, and customers see delayed confirmations.

The lesson is that not-enough-replicas errors are a symptom of a real cluster problem, and the healthy response is to fix that problem, not to loosen the safety rule that revealed it.

It sets the minimum number of replicas, including the leader, that must be in the in-sync set for Kafka to accept writes from producers using acks of all. If the in-sync set is smaller, those writes are rejected.

No. The check is enforced only for full acknowledgement. Producers with weaker acknowledgement are not stopped by it, but they also do not receive its protection.

The broker default is one, meaning the leader alone is enough. For important data, this is usually too weak, and many teams raise the broker default to two.

No. The replication factor is how many copies should exist. The minimum is how many of them must be healthy for a write to be accepted. The minimum must not exceed the replication factor.

A replication factor of three, a minimum of two, and producers with acks of all and idempotence enabled. This tolerates one broker failure for both durability and write availability.

The in-sync set for some partition has dropped below the minimum, usually because of a broker outage, restart, slow disk, or network issue. Investigate why followers left the in-sync set instead of lowering the setting.

Yes, as long as the partition has a leader. The minimum restricts only writes with full acknowledgement. Consumers keep reading committed data.

Not directly, because it is a threshold check. Latency is driven by acks of all waiting for every in-sync replica, and by the replication factor and network distance between replicas.

The minimum decides when writes are accepted. Unclean leader election decides whether an out-of-sync replica may become leader when no in-sync replica remains. For strong durability, keep a sensible minimum and leave unclean election off.

No. Producers choose only acks. The minimum is a broker or topic setting controlled by administrators.

Possibly, particularly with the error where the record was appended before the ISR shrank. Enabling the idempotent producer prevents such duplicates within a producer session.

It can be changed without restarting brokers, and it takes effect immediately. Raising it may instantly block writes on partitions whose ISR is smaller than the new value, so check the cluster’s health first.

Three zones, with one replica in each, so that the loss of a whole zone leaves two replicas and writes continue. With only two zones, one zone holds two copies and its loss breaks the minimum.

Audit topic settings for a minimum of one on important topics, a minimum above the replication factor, a replication factor of one, and producers with weak acknowledgement. Combine this with metrics on under-replicated and at-minimum partitions.

Treat it as a last resort and a temporary measure. The errors mean the cluster lost redundancy. Fix the underlying problem, and if you must lower the value, record it and restore it as soon as the ISR is healthy.

The setting min.insync.replicas is Kafka’s way of saying that a write is only safe when enough healthy copies exist. It counts the leader and the followers that are currently caught up, and it is enforced only when producers ask for full acknowledgement. When the in-sync set is too small, Kafka refuses new writes rather than promise something it cannot guarantee, and readers keep reading committed data throughout.

Good results come from treating the replication factor, the minimum, and the acknowledgement level as one package, usually three, two, and all for important data. Keep the minimum below the replication factor to leave room for maintenance, spread replicas across zones, keep unclean leader election off, monitor partitions at and below the minimum, and fix the causes of shrinking in-sync sets instead of loosening the rule that reveals them.