Kafka Replication Explained: Leaders, Followers, ISR, and Failure Recovery

Kafka replication stores copies of each partition on multiple brokers. One replica leads reads and writes while followers copy its ordered log and stand ready to take over. This design keeps partitions available through many broker failures. It does not create a historical backup or protect every copy from a bad delete.

Key takeaway

Match the protection layer to the failure. Native Kafka replication handles a broker loss. Cross-cluster replication handles a cluster or site loss. An independent backup handles deletion, corruption, and recovery to an earlier point in time.

Replication is not one setting. Its durability comes from the relationship between partition placement, the in-sync replica set, producer acknowledgements, and leader election. A safe design treats those controls as one system.

What Kafka replication does

A Kafka topic is divided into partitions. Each partition is an ordered log, and its replication factor determines how many brokers hold a copy. A replication factor of three means three brokers store that partition: one leader and two followers.

The leader handles normal reads and writes for the partition. Followers fetch new records from the leader and append them in the same order. Kafka distributes leadership across brokers, so no single broker leads every partition.

This model protects against a broker or disk becoming unavailable. If the leader fails, Kafka can elect a current follower and direct clients to it. Other partitions continue through their own leaders while the cluster converges.

Replica count alone does not define safety. Placement matters too. Three copies on brokers in one rack can all disappear with one power failure. Configure rack awareness so replicas occupy distinct failure domains.

The same boundary applies at larger scale. Replicas inside one cluster protect that cluster from component failures. They do not automatically create a second, independent cluster in another region.

How Kafka replication works step by step

Every successful write passes through a short sequence. Understanding that sequence makes the durability settings easier to reason about.

1. The producer selects a partition. Its metadata identifies the broker that currently leads that partition.
2. The producer sends a record batch to the leader. The leader validates and appends the batch to its local partition log.
3. Followers fetch from the leader. Each follower appends the same records in the same order and reports its progress.
4. Kafka advances committed progress. Data becomes committed when the required in-sync replicas have replicated it.
5. The producer receives an acknowledgement. The timing depends on the producer's acks setting and the topic's min.insync.replicas floor.

Followers pull data rather than receiving pushes from the leader. That behavior lets Kafka use the same sequential log and batching patterns for replication that make normal consumption efficient.

Kafka tracks the high watermark for each partition. Consumers do not read beyond committed progress under normal isolation. This prevents them from seeing a leader-only record that could vanish after a failover.

The Apache Kafka topic configuration reference documents the exact relationship between acks=all and min.insync.replicas. Every current in-sync replica acknowledges an acks=all write. The minimum setting decides whether the ISR is large enough to accept it.

ISR, leader election, and broker failure

ISR means in-sync replicas. The set includes the leader and followers that remain sufficiently caught up with it. Kafka removes a follower from the ISR when it falls behind for too long.

An out-of-sync follower still holds data, but Kafka cannot assume it has the latest committed records. It must catch up before it can safely rejoin the ISR. This distinction matters during leader election.

When a leader fails, Kafka normally chooses an eligible replica with current data. Clients refresh their metadata and continue through the new leader. The old leader becomes a follower after it returns and reconciles with the active log.

Unclean leader election changes that safety rule. It permits an out-of-sync replica to lead when no current candidate remains. The partition may return to service sooner, but acknowledged records can be lost.

That trade is explicit: availability now, or confirmed data later. Most systems that cannot recreate events should favor data safety and investigate why the ISR collapsed. A temporary partition outage is visible; silent record loss may not be.

ISR changes also expose early trouble. A follower can fall behind because of a slow disk, network congestion, long garbage-collection pauses, or an overloaded broker. Sustained ISR shrink is an incident signal before a second failure turns degraded redundancy into an outage.

Kafka replication factor, acknowledgements, and minimum ISR

Kafka replication factor answers one question: how many copies should each partition have? It does not say how many copies must receive a new write before the producer sees success.

That second decision comes from acks and min.insync.replicas:

• acks=0 does not wait for a broker acknowledgement.
• acks=1 waits for the leader to append the batch.
• acks=all waits for every replica currently in the ISR.
• min.insync.replicas sets the smallest ISR that can accept an acks=all write.

For important production data, a common baseline is replication factor three, min.insync.replicas=2, and producers using acks=all. This combination permits one replica to become unavailable while two current copies can still confirm new writes.

If the ISR drops below two, Kafka rejects new acks=all writes. Producers receive NotEnoughReplicas or NotEnoughReplicasAfterAppend errors. The failure is deliberate because accepting a leader-only write would break the chosen durability policy.

Configuration	Broker failure behavior	Data risk	Typical fit
RF 1, acks=1	Partition stops if its broker fails	One disk or broker can remove the only copy	Disposable development data
RF 2, min ISR 1, acks=all	Writes can continue on one current replica	A second failure can remove the latest copy	Lower-criticality workloads with accepted risk
RF 3, min ISR 2, acks=all	One replica may fail while writes continue	Strong broker-failure protection	Common production baseline
RF 3, min ISR 3, acks=all	Any missing replica stops writes	Lowest write availability	Narrow cases requiring every copy before success

Producer retries handle temporary request failures. Idempotent production helps prevent duplicates caused by retries. Those client controls strengthen delivery, but neither replaces partition replication.

Likewise, increasing the broker or topic default affects newly created topics. It does not redistribute every existing partition. Changing existing replication requires a planned partition reassignment, with enough network and disk capacity for the copy traffic.

How to inspect replication health

Start with the topic description command shipped with Apache Kafka:

bin/kafka-topics.sh \
  --bootstrap-server broker-1:9092 \
  --describe \
  --topic orders

For each partition, inspect three fields:

• Leader identifies the broker serving that partition.
• Replicas lists every assigned replica, whether current or not.
• Isr lists the assigned replicas that are currently in sync.

Healthy output usually shows an ISR count equal to the replication factor. A smaller ISR means redundancy is degraded. A missing leader means the partition is offline and cannot serve clients.

Do not alert on one number without context. Planned broker restarts can shrink the ISR briefly. Alert on sustained under-replicated partitions, offline partitions, repeated leader elections, and replica lag together.

The response should also match the cause. A slow follower may need disk or network relief. Poor replica placement requires reassignment. An undersized cluster may need more capacity before re-replication can finish safely.

Test the failure path after configuration changes. Stop one broker in a controlled environment, confirm leaders move, and verify producers continue within the agreed error budget. Then confirm the returning broker catches up and rejoins the ISR.

Intra-cluster versus cross-cluster replication

Native partition replication stays inside one Kafka cluster. It is tightly coupled to that cluster's metadata, brokers, and leader elections. It is ideal for broker and rack failures within the cluster's failure boundary.

Cross-cluster replication copies records between independent Kafka clusters. Apache Kafka's MirrorMaker 2 runs on Kafka Connect and creates directional flows from source clusters to target clusters. It can also synchronize selected topic configuration, ACL, and consumer-group information.

The Apache Kafka geo-replication guide explicitly separates these two mechanisms. Common cross-cluster patterns include active-passive disaster recovery, active-active regional service, aggregation, and migration.

Question	Intra-cluster replication	Cross-cluster replication
What does it copy?	Partition replicas inside one cluster	Selected records and metadata between clusters
What failure does it target?	Broker, disk, or rack	Cluster, data center, or region
How does failover happen?	Kafka elects a partition leader	Applications switch to another cluster
Is the copy synchronous?	Coupled to ISR acknowledgements	Usually asynchronous
What defines RPO?	Acknowledgement and election policy	Replication lag at failure time

Asynchronous replication means the target may trail the source. The remaining lag when the source fails is the recovery point objective. Measure it during load and during link degradation, not only when the system is quiet.

For topology guidance, see Kafka replication across data centers. The MirrorMaker best practices guide covers offset checkpoints, internal topics, loop prevention, and failover drills.

Why Kafka replication is not backup

Replication keeps another live copy of the current log. That is valuable for availability, but it shares the source's logical state. Deletes, retention, bad writes, and some operator mistakes can affect every replica.

A replica also lacks arbitrary point-in-time recovery. If an application publishes incorrect events for an hour, the followers correctly copy them. Cross-cluster replication can carry those same records to the standby cluster.

Backup adds a different boundary. It writes data and recovery metadata to independent storage with its own retention. A restore can target a clean time before the logical failure.

Protection layer	Primary goal	Strong against	Does not solve alone
Native Kafka replication	Partition availability	Broker, disk, and rack loss	Cluster loss or rollback to earlier data
Cross-cluster replication	Site availability	Cluster, data center, and regional loss	Propagated deletion or historical restore
Independent backup	Recoverability	Deletion, corruption, long retention, point-in-time restore	Instant traffic failover

Use all three when the workload justifies them. Native replication keeps the active cluster serving. Cross-cluster replication keeps another cluster near the current state. Backup preserves a recoverable state outside both.

The Kafka backup strategies guide explains how those layers fit together. The disaster recovery documentation shows how point-in-time restore complements a standby cluster.

A practical Kafka replication design checklist

Before calling the design finished, verify each part of the durability chain:

1. Define the failure boundary. Decide whether the system must survive a disk, broker, rack, cluster, region, or logical data failure.
2. Place replicas across real failure domains. Broker IDs alone do not protect against shared racks, power, storage, or network paths.
3. Set one durability policy. Treat replication factor, minimum ISR, producer acknowledgements, retries, and idempotence as related controls.
4. Monitor the current safety margin. Track ISR shrink, under-replicated partitions, offline partitions, and leader churn.
5. Exercise leader loss. Verify producer and consumer behavior during a real broker stop, not only through configuration review.
6. Add a second cluster for site failure. Measure cross-cluster lag and test the application switch, including consumer offsets.
7. Add independent recovery. Restore backups regularly and measure the actual recovery time and recovery point.

OSO Kafka Backup stores Kafka topic data and consumer group offsets in Amazon S3, S3-compatible storage, Azure Blob, GCS, or a filesystem. It supports point-in-time recovery with millisecond precision and Zstd or LZ4 compression.

Start with the getting started guide or compare the protection models in backup versus alternatives. Replication keeps the present available. Backup gives you a safe past to return to.

The replication model in one sentence

Kafka replication is a chain. Leaders order writes, followers copy them, the ISR defines current replicas, acknowledgements enforce durability, and leader election restores service after failure.

Design each link for the same data-loss budget. Then add cross-cluster replication for site availability and independent backup for historical recovery. That makes the system resilient to more than the next broker restart.

Frequently asked questions

What is replication in Kafka?

Kafka replication stores multiple copies of each topic partition on different brokers. One replica is the leader and handles normal reads and writes. Followers copy the leader log in order and can become leaders after a failure. The replication factor sets the total number of copies for each partition.

How does Kafka replication work?

A producer writes a record batch to the partition leader. Followers fetch that batch and append it in the same order. Kafka tracks which replicas remain in sync and advances committed progress after the required replicas have copied the data. The producer receives success according to its acknowledgements setting and the topic minimum in-sync replica requirement.

What is Kafka replication factor?

Kafka replication factor is the number of replicas assigned to each partition, including its leader. A replication factor of three creates one leader copy and two follower copies on three brokers. The factor controls copy count, while producer acknowledgements and minimum in-sync replicas control how many current copies must participate before a write succeeds.

What is an in-sync replica in Kafka?

An in-sync replica is a partition replica that remains sufficiently caught up with the leader. Kafka tracks these replicas in the ISR. Current ISR members can participate in acknowledgements and safe leader election. A lagging follower leaves the ISR and must catch up before it can safely rejoin.

Why is replication required in Kafka?

Replication lets Kafka keep partitions available when a broker, disk, or rack fails. Without another current replica, losing the broker that holds a partition removes both its data and its ability to serve clients. Replication does not replace backup because every live replica can still receive the same deletion, bad write, or retention action.