Round-Robin Load Balancing

What's being tested

These problems test stateful request selection: implementing a correct, health-aware round-robin router while servers are added, removed, or marked unhealthy. Interviewers probe index invariants, concurrency safety, fault handling, and whether you can compare simple rotation with consistent hashing when request affinity matters.

Patterns & templates

• Round-robin pointer — keep nextIndex; choose servers[nextIndex % n], then increment; O(1) selection, O(n) storage.

• Health-aware scan — skip unhealthy nodes with at most n probes; return explicit error when no backend is available.

• Dynamic membership invariant — after addServer or removeServer, normalize nextIndex %= len(servers) to avoid out-of-bounds and skew.

• Concurrent router state — protect nextIndex and servers with Mutex/RWMutex, or use atomic index plus immutable server snapshots.

• Retry vs reroute — retry transient failures with bounded attempts/backoff; avoid infinite loops when every backend fails.

• Consistent hashing template — hash each request key and server virtual node; lookup via sorted ring in O(log V), where V = servers * replicas.

• Testing matrix — cover empty pool, one server, unhealthy servers, removal before current index, wraparound, concurrent calls, and distribution sanity.

Common pitfalls

Pitfall: Incrementing nextIndex before validating availability can skip servers or produce uneven routing after failures.

Pitfall: Removing a server without adjusting the pointer causes out-of-bounds errors or repeated routing to the wrong backend.

Pitfall: Claiming round-robin preserves request affinity; use consistent hashing when the same customer/order/session should usually hit the same backend.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.