Why architecture matters here
Realtime features fail in ways request/response services do not, because the unit of state is a connection, not a request. A REST endpoint scales by adding stateless replicas behind a round-robin balancer. A Socket.IO fleet cannot: each client is pinned to one node for the life of its session, each node holds meaningful in-memory state (which sockets exist, which rooms they joined, what is buffered for them), and the load balancer must respect that pinning or the protocol itself breaks — an Engine.IO session established on node A returns '400 session unknown' when its next polling request lands on node B.
Fanout is the second structural difference. 'Emit this message to the 4,000 members of room match:1234' is a broadcast problem, and the members are scattered across every node in the fleet. Without a shared fanout layer, each node only reaches its local members and the feature silently delivers to a fraction of the audience — a bug class that unit tests never catch because tests run one node. The adapter architecture exists precisely so application code can say io.to(room).emit(...) and remain oblivious to topology.
The third difference is correlated failure. When a node dies or a deploy restarts it, ten thousand clients reconnect within seconds — through the full polling handshake, TLS negotiation, auth middleware, and room re-joins. That reconnection storm is the defining load pattern of connection-oriented systems: steady-state CPU may sit at 20%, yet the fleet must absorb bursts an order of magnitude larger, or a single node's death cascades into neighbors dying under the herd, which reconnects again, larger. Architecting for Socket.IO means architecting for that storm on day one.
The architecture: every piece explained
Top row of the diagram: the connection path. Clients — browser or mobile SDKs — connect through a load balancer with sticky sessions, typically via cookie-based affinity (or IP hash where cookies are impossible). Stickiness is non-negotiable while HTTP long-polling is in play, because a single Engine.IO session spans multiple HTTP requests that must reach the same node. Each node is a Node.js process running the Socket.IO server; nodes are identical and share nothing except the adapter and any external stores.
Middle row: per-connection machinery inside a node. The Engine.IO layer owns the transport lifecycle: it answers the initial polling handshake with a session id and configuration (ping interval, ping timeout, max payload), probes for WebSocket upgradability, swaps transports without dropping the session, and runs the ping/pong heartbeat that declares peers dead after pingTimeout. Above it, namespaces partition the application (e.g. /chat vs /admin) with separate middleware and auth, while rooms are lightweight server-side membership sets within a namespace — join and leave are O(1) set operations, and a socket can be in many rooms. Acknowledgements give per-event request/response semantics with timeouts, and each socket carries a send buffer for events emitted while the transport is momentarily unwritable.
Bottom rows: the shared layers. The adapter is the interface Socket.IO calls for every broadcast; the Redis adapter publishes each to(room).emit onto a channel all nodes subscribe to, and each node delivers to its local room members. The streams-based variant adds bounded replay. Connection state recovery buffers recent events per session (keyed by an offset the client echoes back) so a client that reconnects within the window resumes with its rooms restored and missed events replayed, rather than starting cold. A presence store — application-level, usually Redis — maps users to sockets for 'who is online' and direct messaging, and telemetry watches the three numbers that predict outages: sockets per node, event-loop lag, and adapter throughput.
End-to-end flow
Walk one client from cold start to a delivered room message. The SDK issues an HTTP GET to /socket.io/?EIO=4&transport=polling; the balancer sets its affinity cookie and routes to node A, which responds with a session id and heartbeat parameters. The client immediately opens a WebSocket to the same origin as a probe, sends a ping over it, and on pong sends an upgrade packet; Engine.IO switches the session to WebSocket and the polling transport is retired. Auth middleware ran during the namespace handshake — token validated, user id attached to the socket.
The client emits join with a match id; the server handler validates entitlement and calls socket.join('match:1234') — a local set insert, plus (with the Redis adapter) nothing remote: membership stays node-local, which is why cross-node room queries go through the adapter's request/response channel. Now a score update arrives from the backend: an API service calls the emitter (or a node handles a webhook) and runs io.to('match:1234').emit('score', payload). The adapter publishes one message to Redis; every node receives it, checks its local membership set for the room, and writes the event down each member socket's transport. Total added latency: one Redis hop, typically sub-millisecond in-region.
Now the client rides a train into a tunnel. Pings stop; after pingTimeout node A declares the socket dead and fires disconnect. The SDK, back online 20 seconds later, reconnects with backoff plus jitter, presenting its old session id and last-seen offset. If connection state recovery is enabled and the window (say two minutes) has not lapsed, node A — or any node, with a shared recovery store — restores the socket's rooms and replays buffered events in order; the application sees recovered === true and skips its expensive cold-sync path. Past the window, the client performs a full re-join and the application must reconcile state itself, usually by fetching a snapshot and resubscribing.