This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Debug round-robin request router states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Given a list of backends and an incoming stream of requests, implement a round-robin request router that returns the next healthy server for each request. Handle server add/remove and health changes, ensure fair rotation with correct wrap-around, and avoid skipped or duplicated assignments. You are given failing tests indicating incorrect routing—identify and fix the bug, then write tests for single server, multiple servers, removal during routing, and health flapping. Analyze complexity and thread-safety considerations.
Quick Answer: This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Debug round-robin request router states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Round-Robin Request Router with Health and Dynamic Membership
You are given a list of backend servers and an incoming stream of requests. Implement a round-robin request router that returns the next healthy server for each request.
Requirements
Round-robin across servers with correct wrap-around.
Only return healthy servers; skip unhealthy ones.
Support server add and remove at runtime.
Support health state changes at runtime.
Ensure fair rotation (no skipped or duplicated assignments when state changes happen).
If no healthy servers exist, the router should signal that state (e.g., by raising an exception or returning a sentinel).
Bug-Fix Prompt
You are given failing tests indicating incorrect routing order after server removal and during health flapping. Identify the likely bug causing skipped or duplicated assignments and fix it.
Deliverables
Implement the router with the following interface (or equivalent in your language):
add_server(id)
remove_server(id)
set_health(id, healthy: bool)
next() -> id (returns the next healthy server)
Fix the routing bug so that:
The rotation index is correctly advanced only after returning a server.
Removal of a server adjusts the rotation index to avoid skipping or duplicating assignments.
Write tests for:
Single server
Multiple servers
Removal during routing
Health flapping (servers toggling between healthy/unhealthy)
Analyze time/space complexity and discuss thread-safety considerations and mitigations.
Assumptions
Server IDs are unique and comparable (e.g., strings or integers).
If all servers are unhealthy (or there are none), the router returns a defined error or raises an exception.
New servers are appended to the rotation and should be included in subsequent calls to next().
Clarifying Questions to Ask Guidance
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers Guidance
A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions Guidance
What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?