WebSocket provides low-latency, bidirectional communication between clients and servers. It is a widely used solution for building real-time systems. Once a WebSocket connection is established, the underlying TCP connection remains open until either the client or the server closes it, allowing both sides to exchange messages continuously throughout the lifetime of the connection.
As systems grow, the challenge of scaling WebSocket infrastructure becomes important. Broadly, there are two approaches: vertical scaling and horizontal scaling.
In vertical scaling, the resources of a single server — CPU, RAM, and network bandwidth — are increased so it can handle more WebSocket connections. This approach works well for small to medium-scale systems, but only to a certain extent. A single machine cannot be scaled indefinitely, and relying on one server also introduces a single point of failure in systems where high availability is critical.
Horizontal scaling, on the other hand, increases the number of WebSocket servers. This approach improves redundancy and allows the system to scale using inexpensive commodity servers. However, horizontally scaling WebSocket servers introduces additional challenges.
To understand the problem, consider a multiplayer game with two WebSocket servers: A and B. Initially, players P1, P2, and P3 are connected to server A, and game events flow normally between them. Now suppose P1 disconnects and reconnects, but this time the load balancer routes P1 to server B instead of server A. How will P1 continue receiving events generated by P2 and P3?
It turns out, the problem can be solved using a shared message broker such as Redis Pub/Sub. When a WebSocket server receives an event, it publishes the event to Redis. Other WebSocket servers subscribed to the same channel receive the event and forward it to their connected clients. In this example, when P2 or P3 sends a game event to server A, server A publishes the event through Redis Pub/Sub. Server B then receives the event and forwards it to P1.
One important limitation of Redis Pub/Sub is that messages are not persisted. If Redis or a subscriber becomes temporarily unavailable, some events may be lost. Because of this, WebSocket systems are often designed so that occasional dropped events do not break the application. In systems where message loss is unacceptable, additional application-level mechanisms are used, such as acknowledgments, durable queues, event replay, and message persistence.