---
title: "Kafka broker.rack: rack-aware replica placement"
description: "With broker.rack set, each partition keeps one replica in each of three racks. Lose a whole rack and Kafka acks=all writes still commit with 2 in-sync replicas."
url: https://monedula.dev/kafka-simulator/scenarios/rack-aware-placement/
---

# Kafka broker.rack: rack-aware replica placement

Scenario 03.3.1 · Rack-aware placement. Replication · Advanced · about 3 min · Apache Kafka 4.3.

broker.rack spreads replicas across racks; a whole rack can fail and partitions stay available.

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

## What you start with

When broker.rack is set, Kafka spreads a partition’s replicas across racks so no single rack holds them all. This cluster places three replicas over three racks; an entire rack (two brokers) is then killed to show the partition staying available.

## Step by step

1. **Six-broker cluster ready - rack-aware assignment spreads each partition across rack-a / rack-b / rack-c** (t+0.000s): Six brokers over three racks (2 per rack), broker.rack set. Rack-aware assignment places each partition's 3 replicas in three DIFFERENT racks - no rack ever holds two copies of the same partition. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.1&t=0)
2. **Record O1 produced and replicated across all three racks** (t+5.000s): O1 commits with acks=all: the leader and both followers sit in different racks, so every rack now holds a copy of the record. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.1&t=1)
3. **broker-5 and broker-6 (whole rack-c) dead - leaders elected on surviving replicas, ISR ≥ 2 on every partition** (t+8.000s): A whole-rack outage: both rack-c brokers die at once. Because placement was rack-aware, every partition loses exactly ONE replica - leaders re-elect on the survivors and the ISR holds at 2 = min.insync.replicas everywhere. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.1&t=2)
4. **Record O2 produced after rack-c failure - acks=all succeeds with 2 in-sync replicas** (t+10.500s): O2 still commits: with 2 in-sync replicas per partition, acks=all + min.insync.replicas=2 stays satisfiable despite the lost rack - durability against a correlated rack/AZ failure. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.1&t=3)

## The takeaway

Rack-aware placement spreads each partition over min(#racks, RF) racks - here one replica per rack - so a full rack (or availability-zone) outage still leaves enough in-sync copies for the partition to keep serving.

## Configs in this scenario

- [`broker.rack`](https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_broker.rack): The rack or availability zone of the broker; when a topic is created, the replicas of each partition are spread across racks so one rack failing cannot take every copy.
- [`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/)
- [`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/configuration/broker-configs/#brokerconfigs_broker.rack)