Advanced8 min
Network Partition
Cut brokers off from the cluster while their processes keep running, and watch the cluster carry on without them.
In a network partition a broker's process is alive but the others cannot hear it. Brokers keep a session with the controller by sending heartbeats; a broker that sends none before broker.session.timeout.ms (9 seconds by default; about 2 seconds in the simulator) is considered offline. The controller fences it, removes it from the ISRs, and elects new leaders from the remaining ISR members. If the cut-off broker is the active controller, the controller quorum elects a new one, which raises the epoch. Kafka's documentation says the cluster stays available through node failures but may not stay available through network partitions.
The steps use the simulator and name the control to use. The outcomes they describe are what the simulator models; the sources below are what Apache documents.
Steps
0 of 7 steps completed
Verification
The controller is still Broker 3 after the demo, Broker 2 is a healthy follower, and after the reconnect every ISR is full again.
The interview angle
Kafka stays available through node failures after a short fail-over but may not through network partitions. A cut-off broker looks like a crashed one to the controller; with acks=all and min.insync.replicas, a partition refuses writes rather than accept them on too few replicas.
Sources
- Design (4.2 documentation) (opens in a new tab)
- Broker configs (4.2 documentation) (opens in a new tab)
- KRaft operations (4.2 documentation) (opens in a new tab)
- KIP-631: The Quorum-based Kafka Controller (opens in a new tab)
Checked against Kafka 4.2 documentation on 11 October 2026. Draft: not yet reviewed by a Kafka specialist, and releases move on, so confirm against the current documentation before you act on it.