---
title: "Kafka preferred leader election after a rack failure"
description: "A rack dies and leadership piles onto the surviving brokers. It stays skewed after the rack returns, until a Kafka preferred-leader election spreads it back."
url: https://monedula.dev/kafka-simulator/scenarios/leader-balancing/
---

# Kafka preferred leader election after a rack failure

Scenario 03.2.2 · Leader balancing. Replication · Advanced · about 3 min · Apache Kafka 4.3.

A rack dies, leadership concentrates on survivors; restart the rack and a preferred-leader election re-spreads it.

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

## What you start with

Each partition has a "preferred" leader - the first replica in its assignment. When a rack fails, leadership for its partitions moves onto the surviving brokers and piles up there; after the rack is restarted, a preferred-leader election re-spreads leadership back to its original distribution.

## Step by step

1. **Six-broker rack-aware cluster - every partition led by its preferred replica (2 leaders per rack)** (t+0.000s) [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.2.2&t=0)
2. **Record O1 produced and replicated across all three racks** (t+5.000s) [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.2.2&t=1)
3. **rack-c dead - partitions 2 & 5 fail over to survivors; leadership now skewed onto rack-a / rack-b** (t+8.000s): Each partition keeps ≥2 in-sync replicas (one per surviving rack), so acks=all still commits - but the two rack-c-preferred leaders are now non-preferred. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.2.2&t=2)
4. **rack-c restarted - broker-5/broker-6 caught up and rejoined ISR (as followers); leadership still skewed** (t+13.500s): The preferred replicas are back in-sync, but this run has auto.leader.rebalance.enable off, so leadership stays put until a preferred-leader election runs; with Kafka's default the controller would do it within 300 s. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.2.2&t=3)
5. **Preferred-leader election ran - leadership re-spread to the preferred replicas; imbalance back to 0** (t+16.500s) [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.2.2&t=4)

## The takeaway

Failures concentrate leadership on survivors; a preferred-leader election rebalances it once brokers return, keeping any single broker from carrying a disproportionate share of leader traffic.

## Configs in this scenario

- [`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/configuration/broker-configs/#brokerconfigs_auto.leader.rebalance.enable)