<p>If develop a online real time game with websocket, multiplayers running on the different containers, how to sync data when add or reduce containers if they are playing?</p>

<p>Does kubernetes has any good feature on this case?</p>

<p><a href="https://stackoverflow.com/users/5547718/thatbriandude">ThatBrianDude</a> already gave an awesome answer, and mine will not be that good. But I think <a href="https://stackoverflow.com/questions/46952537/how-to-use-kubernetes-to-do-multiplayer-online-game-with-websocket#comment80879143_46952660">your last comment</a> gave us more hints about the architecture you have in mind. I hope my humble answer will shed a light on more ideas to your game. Here are some suggestions:</p>

<p>First, avoid keeping any state in the websocket apps.</p>

<blockquote>
  <p>The basic idea with containers is that they should be stateless.
  <a href="https://stackoverflow.com/a/46952660/5269825">ThatBrianDude</a></p>
</blockquote>

<p>So, why not use caches and a messaging layer to help you with that. Imagine the following examples:</p>

<p>Situation 1: if the client sends an action to the websocket server, the server should put it in a queue/topic (some other service will process it later on).</p>

<p>Situation 2: The server might also listen to a(some) topic(s) for some types of messages, and send them back to the clients that need that information.</p>

<p>Situation 3: when the client asks for information or if the websocket server needs some information to send to the client, the server must read it from a cache, as reading from DB might be slow for a multiplayer game.</p>

<p>Situation 4: eventually a container is killed. The clients connected to that server will receive a connection error, and should reconnect. That means another handshake, and the player might feel it, depending on what the game was doing, so killing a container should not happen that often. But that would be just it, no information is lost.</p>

<p>This way, the websocket server containers are totally stateless, and the messaging topics and caches will help you to: provide all the information needed to containers, and; keep websockets, persistance and processing isolated and scalable.</p>

<p>Summing up, the information would flow like this:</p>

<ol>
<li>clients are showering the websocket server containers with actions</li>
<li>websocket servers just send them to the messaging layer</li>
<li>processing containers (which can be scalled too!) receive those messages, process them, save to the database and/or to a cache and eventually send more messages to other topics</li>
<li>(optional) websocket servers receive those messages and send them to the clients.</li>
</ol>

<p>Or like this:</p>

<ol>
<li>clients ask for information or websocket servers periodically need to send the world state to clients</li>
<li>websocket servers look up the information in the cache</li>
<li>and send it to the clients.</li>
</ol>

<p>Or even like this:</p>

<ol>
<li>Some processing servers are independent of messages, they just read the game/world state (from the cache?) periodically</li>
<li>they process the physics and mechanics of the game</li>
<li>and save the result back in the cache, which will be sent to the clients by the websocket servers periodically, or send it in a topic so the websocket server can listen to it and send it to the clients.</li>
</ol>

<p>Lastly, don't forget the suggestion to have one machine responsible for one game/world. It would be nice if each processing server (or each thread of a server) works with one game/world. That would make it easier to persist things without the need to sync stuff.</p>
