An order service publishes to one topic name, such as orders.placed. Behind that name, several brokers may store different parts of the topic, with additional copies on other brokers. This placement determines where writes go, which machines store the data, and how much work each broker handles.

We’ll build a concrete placement example, follow how applications use it, and examine what changes when the cluster grows. The examples assume a KRaft-based Apache Kafka 4.3 cluster with local broker storage and ordinary consumers reading from partition leaders. The layouts are illustrative assignments, not predictions of the exact placement Kafka will generate.

Kafka distributes a topic by placing its partition replicas on brokers. A partition is an ordered log, and a replica is a copy of that log. Each partition has its own replica assignment, which identifies the brokers responsible for storing it.

Suppose orders.placed has six partitions and a replication factor of 2. There are six independent logs and two copies of each log, giving twelve replicas in total. Replication factor includes the leader copy.

One possible assignment across three brokers is:

Every partition appears on two different brokers. Kafka does not assign two replicas of the same partition to one broker. With three brokers, Kafka cannot provide a replication factor of 4.

The same assignment looks different when you look at each broker separately. In this diagram, P0 means partition 0 of orders.placed, and similarly for the other partition numbers.

Each broker stores four replicas, leads two partitions, and follows two others. No broker stores the entire topic in this layout. Each holds the retained data for the partition replicas Kafka assigns to it.

The two copies of partition 0 contain the same partition history as replication catches up. If an order event occupies offset 42, its copies have offset 42 on both brokers. Replication does not divide that partition into separate ranges, such as offsets 0–99 on Broker 1 and 100–199 on Broker 2.

The replication factor of 2 keeps the example small. Choosing a production replication factor also requires deciding which failures and write-availability requirements the cluster must support.

Publishing involves two related decisions: choosing a partition and finding the broker that leads it.

The producer chooses a partition using its configured routing behavior or a partition the application specifies explicitly. Cluster metadata tells it which broker currently leads that partition. The producer then sends the write to that broker.

Suppose an OrderPlaced event has key ord-1042, and the producer routes it to partition 0. This is an assumed routing result for the example. Under our assignment, Broker 1 receives the write and Broker 2 maintains the follower copy.

The diagram shows the routing decision followed by the resulting record flow. Broker 2 initiates replication by fetching from Broker 1; the replication arrow shows the returned data.

This separation allows Kafka to change the broker serving a partition while keeping the partition’s identity. If Broker 2 becomes the leader of partition 0, producers refresh their metadata and direct writes there. A broker change alone does not change the record key or the partition the producer selects for it.

Consumers use the same leadership information to find the broker serving their assigned partitions. A consumer that owns partitions 0 and 1 can fetch from both Broker 1 and Broker 2. Consumer instances and broker instances do not need to match one for one.

Likewise, the bootstrap broker is an initial discovery point. It does not own every topic the application accesses or forward all its subsequent writes.

When an administrator creates a topic, they can provide a partition count and replication factor and let Kafka choose the replica assignment. They can also supply an explicit mapping from partition numbers to broker IDs.

In a KRaft cluster, the controller handles topic creation and records the assignment in cluster metadata. The brokers use that metadata to establish their local replicas. The controller manages the placement information; brokers store and replicate the order records.

Automatic placement aims to spread replicas and leadership across the available brokers while respecting placement constraints. Where operators configure rack information, spreading copies across racks is also a placement goal. Exact results can vary with cluster topology, broker availability, and the placement implementation.

You should therefore inspect the actual assignment rather than assume that partition 0 always starts on the lowest-numbered broker or that partition numbers follow a permanent broker rotation.

Replica Order and Current Leadership

The ordered list [1, 2] for partition 0 carries more information than membership alone. Broker 1, the first replica, is the preferred leader, the replica Kafka prefers to lead when conditions permit. Kafka tracks the actual leader separately; Broker 2 may hold that role after a failure or maintenance event.

In our initial layout, every current leader is also its partition’s preferred leader. That gives two leaders per broker. Later, the same replica assignments can exist with a different distribution of current leaders.

This distinction matters when examining a cluster. Replica placement answers “where are the copies?” Current leadership answers “which broker is serving leader requests now?”

Our example looks evenly distributed because every broker has four replicas and two leaders. Those counts are useful, but they describe only part of the workload.

Storage Distribution

Suppose each partition has approximately 100 GB of retained log data. Six partitions represent about 600 GB of logical data. With two replicas per partition, the cluster stores roughly 1.2 TB of replica data, or 400 GB per broker in our layout. This simplified estimate excludes indexes, operational headroom, and temporary data during movement.

Now suppose partition 0 grows to 500 GB while the other five remain at 100 GB. Brokers 1 and 2 each store about 800 GB, because both host partition 0. Broker 3 still stores about 400 GB.

All three brokers still have four replicas. Equal replica counts have not produced equal storage use.

Leader Traffic

A similar difference appears in traffic. Suppose partition 0 receives 40 MB/s of new records and each other partition receives 2 MB/s. Broker 1 leads partitions 0 and 3, so its incoming producer traffic is about 42 MB/s. Brokers 2 and 3 each receive about 4 MB/s for their leaders.

Broker 2 also receives partition 0 replication traffic. Broker 1 must send that traffic and serve consumers reading the partition. These figures count only the stated record traffic, before protocol overhead and other broker work.

If Broker 2 became the leader for partition 0, much of its client-serving work would move there. Both brokers would still store the partition and participate in replication. Changing leadership can redistribute some work without relocating the stored copies.

A useful placement review therefore considers replica sizes, write rates, consumer reads, and follower traffic alongside replica and leader counts. Kafka’s initial assignment cannot predict that one customer will later account for most of the orders.

Partition Granularity

The existing partitions limit how widely Kafka can spread the workload. A topic with one partition has one leader accepting its ordinary producer writes, even if the cluster has twenty brokers.

Moving that partition can put its workload on a broker with more spare capacity. It does not split the partition’s write stream across several leaders. Similarly, additional replicas create more copies without creating more independent partitions for a regular consumer group to process.

Different broker IDs do not necessarily mean independent failures. Two brokers can share a physical host, a rack’s power supply, or an availability zone. A failure domain is a group of resources that can become unavailable together.

For our three-broker example, suppose Broker 1 is in zone-a, Broker 2 in zone-b, and Broker 3 in zone-c. Every partition’s two replicas then occupy different zones.

Kafka can use the broker.rack setting to identify these locations. Despite its name, the value can represent an availability zone. Each broker should report the location it actually belongs to.

Rack-aware automatic placement spreads a partition’s replicas across the available racks. With two replicas, a partition can occupy at most two zones; adding a third zone does not create a third copy. Explicit placement plans also need review for failure-domain separation.

Consider what would change if Brokers 1 and 2 shared zone-a. Their assignment [1, 2] would leave both copies of partition 0 exposed to a single zone outage. The replica count would still be two, but the placement would protect against a narrower set of failures.

Spreading replicas helps preserve copies during a location failure. Continued reads and writes also depend on replica state, leader eligibility, acknowledgment settings, and controller availability. Placement is one part of availability, not a complete guarantee by itself.

Suppose we add Broker 4 because the existing machines are running short of storage. Registering the broker makes it available for assignments. In a standard Apache Kafka deployment, joining the cluster alone does not move existing topic replicas onto it. Managed services or external balancing tools may initiate additional placement changes.

To move existing data, an administrator or balancing system requests a replica reassignment, a change to the brokers assigned to a partition.

For partition 0, suppose we replace [1, 2] with [1, 4]. Broker 1 remains the leader in this example. Broker 4 is in zone-b, so the target preserves the separation between the two copies.

The diagram shows the stable assignments before and after the move, with the catch-up phase between them. It describes the requested change, not an automatic consequence of adding Broker 4.

During the transition, Kafka retains the existing replicas while the new replica catches up. After completion, Broker 2 no longer hosts an assigned copy of partition 0, and Kafka can remove that local data. The target replication factor remains 2, even though the move temporarily needs an additional copy.

Moving a large replica consumes disk and network capacity while the cluster continues serving applications. A reassignment can therefore increase load before it relieves it. Movement needs enough temporary capacity and an appropriate transfer rate.

This particular move reduces Broker 2’s stored data and follower work. It leaves Broker 1’s partition 0 leader traffic in place. Whether it solves the original capacity problem depends on which resource lacked capacity.

Partition Identity During Movement

Partition 0 remains partition 0. A retained record at offset 42 keeps that offset in the destination replica. The move preserves the partition log’s identity rather than publishing its contents as new records in another partition.

A consumer’s committed position still refers to the same topic and partition. Moving the replica does not require resetting its offsets. If leadership also changes, clients may need to refresh metadata and retry requests, so do not assume movement causes no interruption.

People informally call several Kafka operations “rebalancing.” Use their specific names to make their effects clear.

Suppose we increase orders.placed from six partitions to nine. The three new partitions create additional places for future records. Existing records remain in partitions 0 through 5; Kafka does not sort them again across all nine logs.

If producer routing depends on the partition count, future records for an existing key may go to a different partition. That can affect how the application preserves order for the key. Moving a replica while keeping the partition count and routing behavior unchanged avoids that particular change.

Likewise, adding consumers can spread processing across more application instances, up to the parallelism available from the topic’s partitions in a regular consumer group. It leaves the broker placement unchanged.

The operation should match the problem. Storage concentrated on a broker calls for examining replica placement. Concentrated leader traffic calls for examining leadership and partition traffic. Slow application processing calls for examining consumers. Each can require a different change, even when the visible symptom is a growing backlog.

Kafka distributes topics through partition replica assignments. Each partition has its own set of broker copies and a current leader, which clients discover through metadata.

Replica counts, leader counts, stored bytes, and traffic describe different aspects of balance. Placement across failure domains also affects which copies can survive an outage.

Adding a broker creates capacity that existing topics use through reassignment. Moving a replica preserves partition identity and offsets; adding partitions and rebalancing consumers change different parts of the system.