---
title: "Kafka replication factor, leader and follower replicas"
description: "RF=3 keeps three copies of a partition on three brokers. The Kafka leader takes the write, both followers fetch it, and the record commits on the full ISR."
url: https://monedula.dev/kafka-simulator/scenarios/brokers-replicas-leader/
---

# Kafka replication factor, leader and follower replicas

Scenario 00.1.5 · Brokers, replicas, leader. Anatomy · Beginner · about 2 min · Apache Kafka 4.3.

RF=3 = three copies on three brokers. One leader serves the partition; followers replicate; the ISR is who’s caught up.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=00.1.5

## What you start with

With replication factor 3, a partition keeps three copies on three brokers. One replica is the leader: it takes all writes and, by default, all reads; the others are followers that fetch from it. Replicas that keep catching up to the leader within replica.lag.time.max.ms form the in-sync replica set (ISR).

## Step by step

1. **One partition · three replicas** (t+0.000s): RF=3 places three copies of the partition on three brokers. Exactly one replica is the leader; the other two are followers that copy from it. min.ISR=2 means at least two replicas must be in-sync to accept an acks=all write. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=00.1.5&t=0)
2. **Leader takes the write** (t+1.400s): By default clients produce to and consume from the leader. The leader appends the record (LEO = 1); the followers have not caught up yet, so it is not committed. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=00.1.5&t=1)
3. **Followers replicate · HW advances** (t+2.200s): The two followers fetched the record from the leader. They never left the ISR (a follower briefly behind stays in-sync), and once every ISR member has the record the high watermark advances to 1. Every broker now holds a committed copy. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=00.1.5&t=2)

## The takeaway

Replication factor sets how many copies exist; one leader handles traffic while in-sync followers stand ready to take over, giving the partition its durability and availability.

## Configs in this scenario

- [`replica.lag.time.max.ms`](https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_replica.lag.time.max.ms): How long a follower may go without fetching, or without catching up to the end of the leader log, before the leader removes it from the ISR (default 30000, 30 seconds).
- [`min.insync.replicas`](https://kafka.apache.org/43/configuration/topic-configs/#topicconfigs_min.insync.replicas): The fewest in-sync replicas, leader included, that must have a write for an acks=all produce to succeed (default 1); with fewer in the ISR the leader rejects the write with NOT_ENOUGH_REPLICAS. [How min.insync.replicas works](https://monedula.dev/kafka-simulator/configs/min-insync-replicas/)
- [`acks`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_acks): How many replicas must have a write before the producer counts it as sent: 0 (none), 1 (the leader only) or all (every in-sync replica, the default, and required for idempotence). [How acks works](https://monedula.dev/kafka-simulator/configs/acks/)

## Further reading

- [Apache Kafka documentation](https://kafka.apache.org/43/design/design/#replication)