Challenge 1: Explain Why Sticky Sessions Matter for Fallback — Possible Solution ==================================================================== WHY LONG-POLLING FALLBACK SPECIFICALLY NEEDS STICKY SESSIONS ---------------------------------------------------------------- A single established WebSocket connection is already, by nature, pinned to whichever backend server accepted its handshake — the TCP connection itself physically exists between the client and that one server process, so there's no routing decision left to make once it's open. In that sense, a raw WebSocket doesn't strictly "need" sticky sessions in order to function AS A CONNECTION, because the connection itself already guarantees it stays on one server. Long-polling fallback is different in a critical way: it isn't one persistent connection at all — it's a SERIES of independent HTTP requests (exactly like Chapter 1's long-polling technique), where each new request is, from the load balancer's point of view, just another ordinary HTTP request that could be routed anywhere. Without sticky sessions, request #1 might land on Server A, and the very next request (moments later, continuing the "same" logical connection) could be routed to Server B by the load balancer — which has no idea these two requests are supposed to be part of the same ongoing conversation. WHY THIS BREAKS THINGS ------------------------ Server B has no knowledge of the session state, room membership, or in-progress conversation that Server A was tracking for that client — each server's Chapter 6-style rooms Map only knows about connections IT personally accepted. If the fallback's individual HTTP requests get scattered across different servers, the "connection" effectively falls apart: messages queued for delivery on Server A are invisible to Server B, and the client's logical session breaks even though each individual HTTP request might return a 200 OK. WHY THIS WORKS AS AN EXPLANATION ----------------------------------- - The key distinction is between a connection that is ONE long-lived TCP stream (true WebSocket) versus a connection that's SIMULATED via many separate short-lived HTTP requests (long-polling fallback) — the former is self-pinning by nature, the latter needs the load balancer to actively enforce the pinning on its behalf, because nothing about an individual HTTP request otherwise indicates it belongs to a specific ongoing session. - This is exactly why sticky sessions are described as necessary "even when the WebSocket transport itself might not strictly need them" — the requirement doesn't come from WebSocket connections themselves, it comes from Socket.IO needing the SAME reliability guarantee to also hold for its fallback mode, which behaves completely differently at the transport level.