Getting a WebSocket demo working takes an afternoon. Getting 40,000 live connections through a deploy, a load balancer timeout and a mass reconnect without an outage is a distributed systems problem, because every open socket is state your infrastructure has to carry, route around and recover. The encouraging part is that the failure modes are well documented, and Slack, Discord and WhatsApp have all published how they carry millions of concurrent connections.
What is a WebSocket? A WebSocket is a persistent, full-duplex channel between client and server over a single TCP connection, standardised as RFC 6455. It begins as an ordinary HTTP request, then upgrades to a two-way channel where either side can push messages at any time, which makes it the default transport for chat, multiplayer games, collaborative editing and live trading screens.
The connection is the architectural problem, not the code
Stateless APIs scale by adding servers, because any server can answer any request. WebSockets break that assumption: each connection is long-lived state pinned to one machine, so a message between users on different servers has to cross the cluster, and the load balancer cannot help after the connection opens. The right first question is not how many connections fit on one box but how, when a message is published, you find every connection that should receive it.
Raw counts are the easier half. WhatsApp ran 2 million TCP connections on one server in 2012, Discord reached close to 5 million concurrent users in 2017 and by 2020 carried over 11 million.
The catch is that idle connections cost little. What kills servers is fan-out: one message to 10,000 subscribers becomes 10,000 writes, TLS encryptions and TCP sends, so capacity planning should start from message throughput and fan-out ratios, not connection counts.
A pub/sub backbone is what makes horizontal scaling possible
Once you run more than one WebSocket server, a message published on any node must reach subscribers on every node. The standard answer is a pub/sub broker such as Redis, NATS or Kafka behind the connection tier, with WebSocket servers kept deliberately thin while all routing goes through the broker. Socket.IO's Redis adapter is the canonical small-scale version of the pattern.
Real-time delivery works best as the last hop of event-driven systems within your backend architecture: services publish domain events to the broker, and the WebSocket tier is simply the subscriber that speaks to browsers. Slack shows the high end, where Flannel, an application-level edge cache, has served over 5 million simultaneous connections and more than a million client queries per second at peak. The lesson is that connection handling, routing state and data caching scale on different curves.
Load balancers and reconnection storms cause the first incidents
A WebSocket must keep talking to the same backend for its whole life, which is why Socket.IO's documentation requires sticky sessions in any multi-server deployment where clients can fall back to HTTP long-polling. Three configuration items cause most early outages: proxy idle timeouts that silently kill quiet connections unless heartbeats fire well inside the window, rolling restarts without connection draining, and default file descriptor limits that cap you long before memory does.
When a server restarts or a region blips, every client disconnects in the same instant, and synchronised retries can keep a service down longer than the original failure. The fix is exponential backoff with jitter, plus the half teams forget: as the websocket.org reconnection guide explains, a reconnect is a state synchronisation problem, so the protocol needs session resumption or sequence-number replay, and short-lived tokens that stay valid across the reconnect window keep the auth service out of the blast radius.
WebSockets are not always the answer
Plenty of "real-time" products move data in one direction only. For dashboards, notification feeds and price tickers, server-sent events run over plain HTTP, reconnect automatically through the browser's EventSource API and pass proxies more reliably than WebSockets' own protocol. The decision rule is short: choose WebSockets when clients send frequent, low-latency messages, and otherwise SSE plus ordinary POST requests covers most products with a fraction of the operational surface. Managed platforms such as Ably and Pusher remove the hardest operational problems in exchange for per-message pricing that grows meaningful at scale, so run the buy-versus-build numbers at projected message volume, not launch volume.
FAQ
How do you scale WebSockets across multiple servers?
Place a pub/sub broker such as Redis, NATS or Kafka behind the WebSocket tier so a message published on any node reaches subscribers on every node. Keep connection servers thin, use sticky sessions at the load balancer where fallback transports need them, and hold shared state in the broker or a fast store.
How should clients handle WebSocket reconnection?
Use exponential backoff with jitter so mass disconnects never produce synchronised retry waves. On reconnect, resume rather than restart: present a still-valid token, re-establish subscriptions and fetch missed messages by sequence number, as described in the websocket.org reconnection guide.
A pre-launch checklist
Pick the transport per feature: WebSockets for bidirectional traffic, SSE for one-way feeds, long polling as fallback.
Stand up the pub/sub backbone and keep WebSocket servers as thin connection holders.
Configure the load balancer for the Upgrade handshake, sticky sessions where needed, and idle timeouts longer than the heartbeat interval.
Implement heartbeats plus client reconnection with exponential backoff and jitter, backed by sequence-number replay.
Add connection draining to the deploy pipeline, then load test fan-out scenarios and instrument reconnect rates.
Real-time work is roughly 5 percent demo and 95 percent operational hardening, and teams that get the fan-out layer right early spend the rest of the project on capacity planning instead of firefighting. At BeyondPixl Studio we design and build production-grade real-time and AI systems for startups and enterprises, so if a WebSocket architecture decision is on your desk, talk to our engineering team about a scaling review.