title: High Availability Websockets Server
body: <p>I want to know the best way to set up a WebSockets server in a high availability (.NET Core) microservices infrastructure.</p>
  
  <p>My current plan is to have two instances of my WebSockets server behind a load balancer, with session affinity so that once a connection is open, subsequent messages return to the same instance. Then if an instance fails, the client will reconnect to another instance.</p>
  
  <p>Is this the best way to set it up or is there a better way? My primary concern is high availability, but I also want to be able to scale horizontally.</p>
  
  <p>Also if a message needs to be broadcast to a browser client then should I use some kind of reliable message queue to be sure that all instances of the WebSockets server know about the message, in case they own the connection to that browser client? The alternative I thought of for this is that if the servers are somehow stateless, with the connection information stored somewhere else (Redis cluster?) then I wouldn't need to notify all the instances because none of them would "own" the connection to that client? Is that possible?</p>
  
  <p>Thanks for any help :)</p>
  
  <p>Chris</p>