## Problem Implement a simulator for a load balancer that routes long-lived WebSocket connections across **m** backend servers. You receive a sequence of textual requests. The simulator must maintain internal state (active connections) and output a **log of successful routings**. You must support these request types (each part includes all prior rules): ### State you must track - For each active `connectionId`: which `serverIndex` it is currently on, and its `objectId`. - For each server: current number of active connections. - Stickiness: active connections sharing the same `objectId` must be routed to the same server (details below). ### Routing rules (applies to any time you need to place a connection) When routing a connection to a server, choose among **eligible servers**: 1. The server with the **fewest active connections**. 2. Break ties by **smaller `serverIndex`**. A server is **ineligible** if it is at capacity. ### Request formats Assume servers are indexed `0 .. m-1`. - `CONNECT connectionId objectId` - `DISCONNECT connectionId` - `SHUTDOWN serverIndex` ### Part 1 — Basic load balancing (`CONNECT` only) For each `CONNECT`, route the new connection using the routing rules above and **log** the successful routing. ### Part 2 — Disconnection (`DISCONNECT`) `DISCONNECT connectionId` removes that active connection (if present) and decrements that server’s load. - `DISCONNECT` produces **no log entry**. ### Part 3 — Object stickiness Each `CONNECT` includes an `objectId`. - If there is **already an active connection** with the same `objectId`, the new connection **must** be routed to the **same server** as those active connections, even if it is not the least loaded. - If there is **no active connection** for that `objectId`, use normal load balancing. ### Part 4 — Server capacity limits You are given an array `capacity[m]`, where `capacity[i]` is the maximum allowed active connections on server `i`. - A server at capacity cannot accept new connections. - If a `CONNECT` has **no eligible server**, it is **rejected**: **no log entry** and **no state change**. - If stickiness requires routing to a server that is full, the `CONNECT` is also **rejected**. ### Part 5 — Server shutdown (`SHUTDOWN`) `SHUTDOWN s` temporarily takes server `s` out of service and evicts **all** active connections currently on `s`. - Evicted connections must be **re-routed one by one** using the **same rules as a new `CONNECT`** (including stickiness and capacity). - Each successful re-route produces a **log entry** (same format as `CONNECT`). - Rejected re-routes produce **no log entry**, and that connection is dropped (becomes inactive). - The shutdown server `s` is considered **unavailable as a target during the re-routing step**, and then becomes **available again immediately after all evictions are processed**, with load 0. - Process the evicted connections **in the order they originally connected to server `s`** (earliest first) to make the outcome deterministic. ## Output (log) Return the list of log entries in order. Each log entry should be: `connectionId serverIndex` Only successful `CONNECT` and successful re-routes during `SHUTDOWN` produce log lines. ## Assumptions / Notes - `connectionId` strings are unique among active connections at the time of `CONNECT`. - If `DISCONNECT` references a non-existent/ inactive `connectionId`, ignore it. ## Constraints (for choosing appropriate data structures) - `1 <= m <= 1e5` - `1 <= number of requests <= 2e5` - `0 <= capacity[i] <= 1e9` - IDs fit in typical string lengths (e.g., up to 50 chars).