Discuss the impact of network topology on Kafka's performance.

Official answer

Map the traffic paths separately: producer-to-leader writes, replica fetches, consumer reads, controller communication and any cross-cluster replication. Latency, bandwidth, packet loss and congestion affect these paths differently.

With replicated acknowledgements, a slow replication path can increase write latency or cause replicas to fall behind. Putting every replica close together can reduce network cost while increasing correlated failure risk. Use rack/zone placement to preserve independent failure domains; rack awareness is not a general promise to minimize cross-datacenter traffic.

Prefer a regional cluster spanning suitable local failure domains when its latency and resilience requirements fit. A cluster stretched across distant regions pays WAN latency and partition risk. Separate regional clusters with mirroring can isolate those failure domains, but introduce asynchronous replication lag and explicit failover/consistency tradeoffs.

Place clients near the intended regional cluster and ensure advertised broker endpoints are reachable. For supported rack-aware fetching, verify client and broker configuration and measure locality; do not assume it is automatically active. Account for egress charges and replica traffic as well as producer throughput.

Measure producer acknowledgement latency, replication lag/ISR changes, fetch latency, errors, bandwidth and end-to-end record age under normal load and a failed link/zone. Keep sufficient capacity for rerouted traffic during failure. A lower offset gap does not necessarily mean lower processing latency, and a geographically distributed layout is not inherently faster.

Sources

Kafka datacenter deployment guidance; replica placement and rack awareness; consumer rack configuration.