Home / Blog / Post

March 2026 • Rich Robertson

Why a Three-Node Kafka Cluster Is Often Preferable to a Five-Node Cluster

A Distributed Systems Perspective

Introduction

A common design assumption in distributed systems is that increasing node count necessarily improves scalability, availability, and fault tolerance. In Apache Kafka, however, behavior is governed less by broker count alone than by the interaction of partition topology, replication factor, quorum semantics, and control-plane coordination. Under common production configurations, a three-node deployment often provides a more effective balance of durability, latency, and operational stability than a five-node deployment, particularly when replication factor is three and strict acknowledgment semantics are used (Apache Kafka, 2026a; Confluent, n.d.-a; Kreps et al., 2011).

Partition Topology as the Primary Scaling Constraint

Kafka is a distributed append-only log in which throughput is achieved primarily through partition-level parallelism rather than broker count in isolation. Its performance model relies on sequential disk access, topic partitioning, and distributed consumption (Kreps et al., 2011). Consequently, adding brokers yields limited benefit unless the workload also scales in partition count and consumer parallelism.

Recent work on partition optimization reinforces this constraint. Broker count must be interpreted jointly with partitioning strategy, replication overhead, and offered load; otherwise, additional brokers may remain underutilized while coordination complexity grows (Raptis & Passarella, 2024).

Durability Is a Function of Replication Semantics

Kafka durability is determined primarily by replication factor, in-sync replica (ISR) membership, and acknowledgment policy. With replication factor three, min.insync.replicas=2, and acks=all, a record is considered committed when replicated to the required ISR quorum (Apache Kafka, 2026a; Confluent, n.d.-a).

Under this configuration, a five-broker cluster does not increase partition-level durability relative to a three-broker cluster, because each partition is still replicated to three brokers. The additional brokers do not participate in the fault tolerance of that partition and therefore do not strengthen its durability guarantee.

Quorum Size and Latency-Fault Tolerance Tradeoffs

Kafka's KRaft architecture applies quorum-based control-plane reasoning informed by Raft consensus principles (Apache Kafka, 2026b; Ongaro & Ousterhout, 2014). The comparison of three versus five replicas in this section refers specifically to controller quorum sizing, not broker count by itself. In combined-mode deployments, where broker nodes also host controller roles, these counts may coincide; in deployments with dedicated controllers, they can be configured independently.

More generally, configurations with 2f+1 replicas tolerate f failures: three replicas tolerate one failure, whereas five replicas tolerate two. This additional fault tolerance is not free. Larger replica sets require larger quorums and increase coordination overhead in commit paths. In many workloads, single-failure tolerance is sufficient, and the operational and latency costs required to tolerate two simultaneous failures are not always justified.

Write-Path Sensitivity to Slow Replicas

Kafka's write path must satisfy configured durability semantics before acknowledging producer requests. With acks=all, completion depends on replication to all required in-sync replicas (Confluent, n.d.-a). Sensitivity to slow replicas increases when the per-partition replica set is expanded, such as when replication factor increases from three to five; this effect does not follow from broker count growth alone when replication factor remains fixed.

Under common production conditions with network variability and uneven resource contention, larger replica sets can increase tail latency due to higher straggler exposure. Kafka performance guidance consistently frames this as a durability-throughput-latency tradeoff rather than an implementation anomaly (Confluent, 2020).

Control-Plane Growth with Cluster Size

In KRaft mode, Kafka maintains metadata through a controller quorum that tracks topics, partition leadership, ISR state, and configuration changes (Apache Kafka, 2026b; Confluent, n.d.-b). Increasing broker count expands the state space that this control plane must manage.

A larger cluster introduces more communication paths, more placement combinations, and more transitions during rebalance and recovery events. Even when per-partition durability is unchanged, the control plane must converge a more complex system state, which can reduce operational stability under degraded conditions.

ISR Dynamics Under Larger Replica Sets

Kafka relies on ISR membership to determine replicas eligible for committed writes. Replicas that lag beyond configured bounds leave the ISR until they catch up (Apache Kafka, 2026a; Confluent, n.d.-a). Increased ISR churn is most directly associated with larger per-partition replica sets (for example, higher replication factors), not with broker count increases alone under a fixed replication factor.

Larger clusters can still experience more ISR-related events through other mechanisms, including higher total partition counts, more leaders to monitor, and greater aggregate rebalance activity, all of which can increase behavior variability during transient faults or load spikes.

Efficiency of Resource Utilization

Kafka is optimized for high-throughput sequential I/O and partition-local processing (Kreps et al., 2011). Efficient operation therefore depends on matching broker count to partition density and workload distribution.

In many deployments, a three-node cluster with appropriate partitioning achieves high utilization and predictable performance. By contrast, a five-node cluster may distribute the same workload more thinly, increasing metadata and coordination overhead without proportional throughput benefit. Empirical partitioning studies similarly emphasize alignment between workload characteristics and cluster topology rather than maximizing node count in isolation (Raptis & Passarella, 2024).

Conditions That Justify Five Nodes

A five-node deployment is appropriate when explicit requirements demand it, including tolerance for two simultaneous broker failures, very high partition counts, distribution across multiple failure domains, or additional storage and workload-isolation capacity. Under those constraints, higher complexity is an intentional trade for stronger resilience or scale properties.

Conclusion

Kafka cluster design is shaped principally by replication semantics, quorum behavior, and partition topology rather than broker count alone. Under common production configurations, three-node clusters with replication factor three frequently deliver sufficient durability with lower coordination overhead and lower latency variance than five-node alternatives. Five-node designs remain valuable where stricter failure tolerance or larger capacity targets are explicit system requirements.

References

What to Read Next

For a broader view of my distributed systems engineering work, see Distributed Systems Engineering: Correctness, Coordination, Reliability.

For the broader hyperscale challenge, see Kafka at Hyperscale. For the consensus and replication fundamentals behind these cluster-size trade-offs, see Raft vs Paxos vs EPaxos: A Practical Guide.