Distributed WebSockets*

With a single server, WebSocket messaging is straightforward: keep a map of open connections, look up the recipient, and write to their socket.

That breaks as soon as you run more than one instance for load balancing or availability. Server 1 has no idea which users are connected to Server 2, so a message from a user on one server to a user on another simply never arrives.

Each server keeps its own local connections, and two shared services let the servers cooperate without knowing about each other directly.

• Redis is the connection registry. When a user connects to any server, their user ID is mapped to that server's ID, so every instance can look up where anyone is connected.
• RabbitMQ routes messages between servers through a topic exchange. Each server subscribes to its own routing key, server.{serverID}, and delivers whatever arrives on it to its local connections.
• When both users are on the same server, Redis and RabbitMQ are skipped entirely and the message is delivered directly.

When a user on Server 1 messages a user on Server 2, Server 1 first checks its own connections. When the recipient is not there, it asks Redis which server they are on, then publishes the message to RabbitMQ with that server's routing key. Server 2 receives it on its queue, finds the recipient among its local connections, and writes it to their socket.

Every frame records where it came from and how it was delivered (from_server, to_server, and a route of local or rabbitmq), and the sender receives an acknowledgement, or an error if the recipient is offline.

Users connected to different instances can message each other as if there were a single server, and the WebSocket code stays close to a single-server version. The live demo puts two people in a room, one on each server, and shows the route every message takes: from one server, through RabbitMQ, to the other.