title: SockJS and meteor: what if load balancer do not support sticky sessions?
body: <p>I'm exploring balancing options for Meteor. <a href="http://meteorhacks.com/load-balancing-your-meteor-app.html" rel="nofollow">This</a> article looks very cool and it says that the following should be supported to load balance Meteor:</p>
  
  <ol>
  <li>Mongo optailing. Otherwise, it may take up to ten seconds for one instance of Meteor to get updates from the another, because polling Mongo driver will be used, which polls-and-diffs DB each ten seconds.</li>
  <li>Websocket. It's clear too - otherwise clients will fallback to HTTP and long-polling, which will work, but it's not as cool as Websocket.</li>
  <li>Sticky sessions 'which are required by SockJS'. Here the question comes:</li>
  </ol>
  
  <p>As I understood, 'sticky sessions support' is something that assign one client to the same server during his session. Is it essential? What may happen if I don't configure sticky sessions at all?</p>
  
  <p>Here's what I came up to by myself:</p>
  
  <ol>
  <li>Because Meteor stores all data sent to client in memory, if client connects to X servers, then X times more memory will be consumed</li>
  <li>Some minor (or major, if there are no oplog) lag may appear for the same user in, say, different tabs or windows, which may be surprising.</li>
  <li>If SockJS reconnects and wants some data to persist across reconnections, it gonna have a bad time. I'm not sure about how SockJS works, is this point valid?</li>
  </ol>
  
  <p>What bad can happen? These three points doesn't look very bad: data is valid, available, may be at a cost of extra memory consumption.</p>