Scenario 00.1.5 · Brokers, replicas, leader

Kafka replication factor, leader and follower replicas

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.

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: step 1, One partition · three replicas
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: step 2, Leader takes the write
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: step 3, Followers replicate · HW advances

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 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 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
• 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

Embed this scenario

Paste this into a blog post, a course page or your team's docs. The scenario plays inside your page, and the link under it points readers to this walkthrough.

<iframe src="https://monedula.dev/kafka-simulator/embed/?scenario=00.1.5" title="Kafka Simulator: Brokers, replicas, leader" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/brokers-replicas-leader/">Kafka replication factor, leader and follower replicas</a></p>

Further reading

Apache Kafka documentation

More in Anatomy

• Kafka topics, partitions and offsets explained
• Kafka write path: one record from producer to consumer
• Kafka message keys: how a key picks the partition
• Kafka offsets are per partition, not global
• Kafka high watermark vs log end offset (LEO)
• Why Kafka consumers cannot read past the high watermark
• Kafka log start offset: why the earliest offset is not 0

All scenarios