WebSockets — Part 2: Production Architecture and Scaling

What is this?

Part 1 gave you one beautiful open phone line between a client and a server. This part asks the uncomfortable follow-up: what happens when you need a million of those lines at once?

Here's where WebSockets get genuinely hard, and it comes down to one word: state. A normal web request is a stranger — it walks up, gets served by any available server, and leaves. The server remembers nothing. But a WebSocket is a guest who stays. One specific server is now holding that connection in memory for hours. That single fact — connections are sticky and stateful — breaks most of the easy scaling tricks you'd reach for, and everything in this chapter is about working around it.

The one-line idea: scaling WebSockets is the art of managing millions of long-lived, stateful connections spread across many servers — routing each user to the right one, getting messages between servers, and surviving when a server holding thousands of live connections suddenly dies.