I want to know the best way to set up a WebSockets server in a high availability (.NET Core) microservices infrastructure.
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.
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.
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?
Thanks for any help :)
Chris
Your design sounds good. With haproxy you can limit number of clients connections to any given instance which is a huge issue with websockets. I would take the stateless approach and handle errors with code. When a client detects failure, just re-connect to any instance. Keep all persistent data in some kind of global store. Depending on use case, as you mentioned, Redis would work great.
As a side note, Websockets keeps persistent connections open and depending on volume you might need a pool of haproxy instances. Would recommend at least two as starting point for availability.