Route Requests with Round Robin and Consistent Hashing

A traffic router has pod, backend, request, and router abstractions. It should distribute requests in round-robin order across available pods while skipping unavailable ones. Explain the correct routing state and how you would isolate logic defects in an implementation. Then replace the selection policy with consistent hashing so requests from the same user tend to reach the same pod and membership changes remap only a limited portion of traffic, improving the usefulness of per-pod session caches. ### Constraints & Assumptions - The faulty code and test suite are not supplied; do not claim a particular bug exists. - Define behavior when all pods are unavailable and when availability changes during routing. - Hash function, virtual-node count, and concurrent membership-update semantics are design choices to clarify. ### Clarifying Questions to Ask - Is round-robin state maintained per backend, and what counts as an available pod? - What stable user key is available, and should unavailable pods be removed from the ring or skipped? - Must a lookup use one consistent membership snapshot? ### Part 1 — Round-Robin Selection Describe cursor advancement, availability checks, and finite termination. #### What This Part Should Cover - Rotation across eligible pods without repeatedly favoring the same one. - Bounds on scanning and explicit no-available-pod behavior. - Concurrency and focused examples that expose state errors. ### Part 2 — User-Affine Hash Routing Describe the ring, lookup, membership changes, and implications for session caches. #### What This Part Should Cover - Stable key hashing, clockwise successor, and wraparound. - Preserved existing token assignments and limited remapping. - Availability policy and the difference between affinity and guaranteed cache hits. ```hint Trace a successful selection after several unavailable pods, then inspect where the next request begins. ``` ### What a Strong Answer Covers The answer should specify the state invariants for both policies and explain how failures or membership changes affect them. It should reason from the reported behavior rather than inventing a line-level fix for code that is absent. ### Follow-up Questions - How would two router instances agree on the same hash ring? - Why can virtual nodes improve balance without eliminating hot-user load? - What happens to session data when a pod disappears?