I'm designing a lobby which holds all game rooms

  • If a room is empty, it gets deleted by the lobby
  • If a room is full, a new room is created
  • For now the lobby is an array of objects on a websockets server which holds the room.
  • The rooms are are arrays of objects which hold the players.

The players data are stored on firebase, I don't care about the room data, they're just spawned and deleted, therefore they're not stored anywhere now. The problem I'm facing is the following:

  • If I leave it like that, I'm going to face problems when scaling on multiple servers, plus it I don't think I can get away with an array holding 50k arrays which holds players data.
  • I don't want to install redis, every time I have to use that I have stringify and serialize.
  • Using a database like MongoDb, means installing a database, doing read and write, perhaps managing clusters, all that for data I don't care about.
  • Using firebase, means doing too many unnecessary requests

My architecture is simple

  • The client is the mobile app
  • The game logic is done on the server using nodejs
  • Data storage and authentication is done on firebase, using nodejs, from the server side
  • The websockets server is uwebsockets.js

I have to solve the last part which is the rooms and lobby, If I manage to do it without installing a database it would be great, because as of now, I managed to do everything without needing a database on the server, which means easier to scale and all the server has to do is run some nodejs code.

  • \$\begingroup\$ RethinkDB? \$\endgroup\$
    – Lynob
    May 19, 2019 at 19:26

1 Answer 1


Generally speaking, data at rest belongs into the databases and data in use belongs into the RAM of the application server. Which database technology you use doesn't change this basic principle much.

That means that if you have any data about offline players, that data should be in the database until that player decides to log in again. But any data of players which are online right now should be in the RAM of the server for faster access.

So your lobby server doesn't need to hold the data of all players. It only needs to hold the data of those players who are currently in the lobby. And it likely doesn't even need all the data about the players. It only needs the data which is relevant for matchmaking.

If you really need multiple lobby servers, you should synchronize their data via your own network protocol. But I really doubt that this will be necessary. I mean, what does a lobby server do? Keep a list of ongoing matches and online players, send these lists when a client connects and propagate updates to the connected clients when these lists change. These change events happen every few seconds tops and none of these events are latency-critical. Unless you expect to get as big as Fortnite or Counter Strike, one global lobby server should be able to handle it.

The actual load of the game (the "rooms") is handled by the gameservers. Investing into a scalable design from the get go is definitely a good approach here. If your matches are small, then it's a good approach to start a game thread for every ongoing game and terminate the thread when the game is over. When the lobby server tells the players the IP and port of their gameserver, you basically already have an architecture which supports scaling to multiple physical servers. (Scalable architectures for open world MMOs are a far more complicated topic, but this is out of scope for this question).

The gameservers should use the database as little as possible and keep data in memory. Communicating with a database usually takes far too long for real-time gameplay, even when the database server is in the same server rack. So the gameserver should request all the data about a player when that player joins its game, write that data back to the DB when the player leaves and maybe write data back at periodic intervals of several minutes to avoid data loss in case of a server crash (but the necessity of that is debatable depending on how much persistence you have in your gameplay and how stable your gameserver runs). But the actual gameplay loop should operate only on data in the RAM of the gameserver.

I am looking forward to playing your game.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .