Simulate sticky load balancer with shutdown

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).