Why Kafka Sticks to Master‑Write/Read: The Real Reason It Doesn’t Support Read‑Write Separation

In Kafka, both producers and consumers interact with the leader replica, implementing a master‑write master‑read model.

Kafka does not support a master‑write slave‑read (read‑write separation) model, and here's why.

From a code perspective it could be added, but the benefits are limited. A master‑write slave‑read can offload load to follower nodes and prevent the leader from being overloaded.

However, it brings two major drawbacks:

Data consistency issues : there is a latency window when data is replicated from leader to follower, causing stale reads.

Latency problems : replication involves multiple network and disk hops, making it slower than systems like Redis.

In many real‑world scenarios applications can tolerate some latency and temporary inconsistency.

Is it necessary for Kafka to support master‑write slave‑read?

While it can distribute load, Kafka already achieves high load balance under the master‑write master‑read architecture. The following diagram shows a typical Kafka cluster with three partitions and three replicas evenly spread across three brokers.

Each broker handles both produce and consume traffic from the leader replica, resulting in balanced read/write load. Nevertheless, load imbalance can still occur due to uneven partition assignment, skewed producer or consumer traffic, or uneven leader election after broker failures.

Mitigation measures include using Kafka’s built‑in partition‑assignment algorithms for balanced distribution, customizing allocation if needed, and leveraging priority‑based leader election together with monitoring, alerting, and operations platforms to maintain balance.

Overall, Kafka’s master‑write master‑read model offers several advantages: simpler code, finer‑grained load distribution, no added latency, and strong consistency when replicas are stable, making a separate master‑write slave‑read feature unnecessary.