title: SocketIO scaling architecture and large rooms requirements
body: <p>We are using socketIO on a large chat application.</p>
  
  <p>At some points we want to dispatch "presence" (user availability) to all other users. </p>
  
  <pre><code>io.in('room1').emit('availability:update', {userid='xxx', isAvailable: false});
  </code></pre>
  
  <p>room1 may contains a lot of users (500 max). We observe a significant raise in our NodeJS load when many availability updates are triggered.</p>
  
  <p>The idea was to use something similar to redis store with Socket IO. Have web browser clients to connect to different NodeJS servers.</p>
  
  <p>When we want to emit to a room we dispatch the "emit to room1" payload to all other NodeJS processes using Redis PubSub ZeroMQ or even RabbitMQ for persistence. Each process will itself call his own <code>io.in('room1').emit</code> to target his subset of connected users.</p>
  
  <p>One of the concern with this setup is that the inter-process communication may become quite busy and I was wondering if it may become a problem in the future.</p>
  
  <p>Here is the architecture I have in mind.</p>
  
  <p><img src="https://i.stack.imgur.com/HbtlH.png" alt="enter image description here"></p>