Stripe Load Balancer WebSocket Router (Online Assessment)

Overview

You are asked to simulate a Stripe-style load balancer that routes WebSocket CONNECT/DISCONNECT/SHUTDOWN requests across numTargets servers, each with capacity maxConnectionsPerTarget. Requests are processed sequentially; successful CONNECTs must append a log tuple (connectionId,userId,targetIndex). If you include an optional objectId, that enables sticky routing: all active connections for that objectId must live on the same server.

What you'll implement

• CONNECT: pick a non-full target with the fewest active connections (tie → smallest index). If objectId is present, honor an existing sticky binding or create one on the chosen target. Log successful connects as (connectionId,userId,targetIndex). Rejected connects produce no log.

• DISCONNECT: free the connection’s slot; if it was the last connection for an objectId on that server, release the sticky binding. No output.

• SHUTDOWN: temporarily remove a target, evict all its active connections, and attempt to reallocate evictees to other targets using the same routing rules (process evictees in ascending connectionId order). After reallocation, the target returns with zero active connections.

Flow & implementation signals

You should simulate state with a hash table mapping connectionId → (target, userId, optional objectId) and objectId → target for sticky bindings. Use a min-structure (heap / ordered set) or maintain counts to select the least-loaded non-full target efficiently. Eviction requires sorting evictees by connectionId (or storing them ordered). Expect to demonstrate greedy placement, efficient updates on connect/disconnect, and correct lifecycle handling of sticky bindings.

Skills this tests

You’ll show proficiency in hash tables, heaps/priority queues (or balanced selection strategies), greedy allocation, deterministic tie-breaking, careful state updates, and handling corner cases (full cluster, repeated SHUTDOWNs, object binding release).