title: Scaling WebSockets with a Message Queue
body: <p>I have built a <code>WebSockets</code> server that acts as a chat message router (i.e. receiving messages from clients and pushing them to other clients according to a client <code>ID</code>). </p>
  
  <p>It is a requirement that the service be able to scale to handle many millions of concurrent open socket connections, and I wish to be able to horizontally scale the server.</p>
  
  <p>The architecture I have had in mind is to put the websocket server nodes behind a load balancer, which will create a problem because clients connected to different nodes won't know about each other. While both clients <code>A</code> and <code>B</code> enter via the <code>LoadBalancer</code>, client <code>A</code> might have an open connection with node <code>1</code> while client <code>B</code> is connected to node <code>2</code> - each node holds it's own dictionary of open socket connections. </p>
  
  <p>To solve this problem, I was thinking of using some MQ system like <code>ZeroMQ</code> or <code>RabbitMQ</code>. All of the websocket server nodes will be subscribers of the MQ server, and when a node gets a request to route a message to a client which is not in the local connections dictionary, it will <strong><code>pub</code></strong>-lish a message to the MQ server, which will tell all the <strong><code>sub</code></strong>-scriber nodes to look for this client and issue the message if it's connected to that node. </p>
  
  <p><code>Q1:</code> Does this architecture make sense?</p>
  
  <p><code>Q2:</code> Is the <strong><code>pub-sub</code></strong> pattern described here really what I am looking for?</p>