Multiple Node/Express/Socket.io servers for game lobbies?

Question

Building a multiplayer game on the web that will be able to handle thousands of players at once, separated into independent lobbies/sessions. There may be 20 players in one lobby, 10 in another, 30 in another, etc.

I'm using NodeJS, Express, and Socket.io, but I'm not sure on a few things. I assume my entire application will run on a single NodeJS server, but that each game lobby will have spawn their own express server and or their own socket.io server.

Alternatively, they may all share the same central single express server, but that express server will produce independent socket.io servers for them (if even possible)

The least likely scenario to me would be to have only one socket.io server for all lobbies as well, and divy them up using socket.io's "rooms" feature. That seems incorrect given that rooms are a server-side only concern, all client's' would emit to the same server likely impacting performance.

To formalize my uncertainty into four questions:

Will it all run on a single NodeJS instance?

Will I want multiple Exress/HTTP servers?

Will I have multiple Socket.IO servers?

What are the implications/requirements on multi-threading/concurrency?

Answer 1

This is a pretty large question and the answer is "It Depends".

You'll see benchmarks for hundreds of connections on a single node.js instance, but those are normally useless because they're not really doing any "work". Just sending messages without any processing. That's not what your server will likely be doing so they're not that helpful. There is some load testing information on the socket.io website that will probably be more helpful to ensure that your particular game would scale.

That being said some considerations:

Scaling sockets can be tough. When you introduce multiple servers then you need to introduce a way to ensure that users that are in the same game lobby are actually connecting to the same socket.io instance so that you're not communicating between users across the network. This may be difficult or trivial depending on how you let users join lobbies (maybe they can only see lobbies on the same instance they're connected to).

When you're spawning a separate socket.io instance for your game lobby, if it exists on the same instance (IE: you're using fork or some subset) then you're still limited by the hardware of the host system anyway.

If you're spinning up individual processes for each game lobby, then I'm not sure if you really care that much about concurrency/multi-threading wrt to your game itself. The fact that you can split it into lobbies to me means that whatever happens within that lobby is constrained within it and shouldn't affect anything outside the lobby (except maybe the player). The problems you'll encounter with concurrency/multi-threading is reaching "across". That is whenever you need to touch something that another process is touching. Without knowing anything about your game it's hard to say where you'll run into issues.