---
title: "Kafka network partition: the majority side keeps writing"
description: "Split broker-1 off from brokers 2 and 3 mid-stream. The side still reaching the Kafka controller commits O3 and O4 to HW 4; broker-1 stays frozen at offset 2."
url: https://monedula.dev/kafka-simulator/scenarios/minority-vs-majority/
---

# Kafka network partition: the majority side keeps writing

Scenario 08.0.3 · Minority vs majority. Chaos · Intermediate · about 3 min · Apache Kafka 4.3.

With a producer and consumer running across a split, the majority side keeps advancing the high watermark while the isolated minority is frozen at the pre-split offset.

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

## What you start with

The companion to the split-brain scenario, run with a producer and consumer active across the split so the asymmetry is visible. After two records commit on all three replicas, the network splits {broker-1} from {broker-2, broker-3}; the controller, still reachable from the majority side, elects a leader there that keeps committing, while the isolated broker is fenced and left with no leader.

## Step by step

1. **Healthy cluster** (t+1.000s): Three brokers, RF=3, min.ISR=2, plus consumer c1 reading partition 0. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=08.0.3&t=0)
2. **O1,O2 committed, consumer caught up** (t+5.000s): O1,O2 commit on all three (HW=2); c1 polls up to offset 2. Producer, consumer and replicas are all in sync. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=08.0.3&t=1)
3. **Split: broker-2 elected, broker-1 frozen** (t+8.000s): The network splits {broker-1} | {broker-2, broker-3}. The controller, still reachable from broker-2 and broker-3, elects broker-2 from the ISR; the isolated broker-1 is fenced and frozen at offset 2. No new writes yet, so the HW is still 2. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=08.0.3&t=2)
4. **Majority makes progress (HW=4)** (t+12.000s): O3,O4 commit on the majority ISR {broker-2, broker-3} and the HW advances to 4; c1 reads them. Meanwhile broker-1 is stuck at LEO 2 - availability follows the side that can reach the controller. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=08.0.3&t=3)
5. **Healed: minority catches up** (t+16.000s): On heal, broker-1 fetches O3,O4 (LEO 2→4) and rejoins the ISR. The minority lost no committed data - it simply could not make progress while isolated. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=08.0.3&t=4)

## The takeaway

Availability follows the side that can reach the controller and still meets min.insync.replicas - here the majority, which keeps advancing the high watermark and serving reads, while the isolated broker makes no progress until the partition heals and it catches up on what it missed.

## Configs in this scenario

- [`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/)

## Further reading

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