<p>I want to architect a message application using Websockets running on Kubernetes and want to know how to solve some problems...</p>

<p><strong>Context</strong></p>

<p>So, say you are building a chat application... Your chat application needs to frequently communicate with the back-end to work (e.g. receive sent messages, send messages etc.), so assuming the back-end will be built using Node &amp; the front-end is built using Electron, I think it would make sense to use Web-sockets in this scenario.</p>

<p><strong>Problem 1 - Load Balancing</strong></p>

<p>Your Web-socket server is suffering from bad performance, so you want to fix that. In this scenario I think it would make sense to make several instances of the Web-socket server &amp; balance the incoming traffic among them equally (load-balancer). For HTTP/HTTPS requests this makes sense, which server instance the request is redirected does not matter as its a "one time" request, but Web-sockets are different, if the client connected to instance 3, it would make sense if the rest of the incoming requests came into instance 3 (as the server might keep client state (like whether or not the client is authenticated))</p>

<p><strong>Problem 2 - Division by Concerns</strong></p>

<p>As the chat application gets bigger &amp; bigger, more &amp; more things need to be handled by the Web-socket servers... So it would make sense to split it into different concerns... (e.g. messaging, user authentication etc.) But assuming client state has to be kept, how can these different concerns know that state? (Shared state among concerns)</p>

<p><strong>Problem 3 - Event Emitting</strong></p>

<p>You implemented an event which fires, for each client, every time a user sends a message. How can this be achieved when there are several instances? (e.g. Client 1 is connected to Web-socket server instance 1, client 1 sends a message... Client 2 is connected to Web-socket server instance 2 &amp; the event needs to be fired for the client...)</p>

VimHax
<h2>Websockets: One request - long running connection</h2>

<p>Your problem about <strong>Load balancing</strong> will be handled. Clients will be load balanced to different instances. When using Websockets, clients do <strong>one request</strong> to connect, they then keep that TCP connection to the backend and send multiple messages on the <em>same connection</em>.</p>

<h2>Separation of concerns</h2>

<blockquote>
  <p>more things need to be handled by the Web-socket servers... So it would make sense to split it into different concerns... (e.g. messaging, user authentication etc.)</p>
</blockquote>

<p>Yes, you should do <a href="https://en.wikipedia.org/wiki/Separation_of_concerns" rel="nofollow noreferrer">separation of concerns</a>. E.g. you could have one authentication service do a <a href="https://openid.net/connect/" rel="nofollow noreferrer">OpenID Connect</a> authentication, and the user can use the <em>access token</em> when connecting with e.g. Websockets or send other API requests.</p>

<p>A web client usually allow up to two Websocket connections to the same domain, so it is better to only have one Websocket service. But you could you some kind of message broker, e.g. <a href="https://www.hivemq.com/blog/mqtt-essentials-special-mqtt-over-websockets/" rel="nofollow noreferrer">MQTT over Websocket</a> and route messages to different services.</p>

<h2>Emitting messages</h2>

<blockquote>
  <p>You implemented an event which fires, for each client, every time a user sends a message. </p>
</blockquote>

<p>If you use a message broker as I described above, all clients can <em>subscribe</em> to <em>channels</em> and when you <em>publish</em> a message, it will be routed to all subscribers.</p>
