Investigate the possibility of achieving elastic horizontal scaling without any drastic code overhauls

[dennyabrain]

We want to be able to support elastic horizontal scaling to be able to support atleast 1000 simultaneous gameplays. This is needed so that we can start promoting viral spiral with full force. Incase we catch attention of new users and get spikes of new rooms, their gameplay experience should not be marred by crashes and buggy game.

Even though there are a few things that could be drastically changed to achieve this, thats not in scope for this issue. What we want to do as of now, is do this with as few changes as possible to the code. So even if this means not optimizing the performance and just throwing money to scale machines, its an acceptable solution for this investigation.

The way the server is written as of now, it requires a certain amount of memory to run and it can easily accomodate a gameplay with n users without any noticeable delay. Theoretically if you were to run 1000 of these servers you could run 1000 games simultaneously. The one bottleneck would be the centralized database. So obviously there is a limit to scaling this up. But I am operating under the assumption that we wont need to scale the database horizontally for this.

The practical problem with this approach is that the way loadbalancing works, its not possible to ensure that the client requests for a particular room goes to the same server. Which adds the complexity of having to ensure state replication across these servers. Which again is out of scope for this issue.

What we want to check is if its possible to route client requests for a particular game room to the same server. This way you could run a 1000 nodes of our python backend server and run 1000 games on them. The scope of this task is to investigate if this is possible technically and if its a smart thing to do financially.

[dennyabrain]

Must investigate Dynamic Request Routing on fly.io for this purpose.