1
\$\begingroup\$

For this post, we'll assume my game is multiplayer chess as it essentially requires the same functions. User logs in to the server and requests a game - the server provides a simple matching service and once done, they start the game. They get 30 seconds timed by the server per turn with 6 players in each game and however many spectators (probably very limited).

I would like to know how you would scale this.

I've considered two options:

Option 1

1) Main server to handle login / match making (which regardless of user numbers should be a fairly easy task)

2) Start new Node servers for each game that close when the game ends.

I'm not entirely sure how this could be implemented yet. (i.e. would the user connect to the main server still and the requests just be passed to the new server or would the user change connection to the new server and then back again when done? changing connection would reduce the load even further and as the two servers won't require communication between them, should be fairly simple)

Option 2

Have 1 Node server and somehow scale it.

--

Suggestions / input?

I'm planning on hosting on Amazon AWS and am well aware that the chances of my game even warranting this level of detail are probably nil but I'm taking this as a learning opportunity.

Thanks.

\$\endgroup\$
2
  • \$\begingroup\$ Well, your players are making one move (which is just a few bytes) every 30 seconds. That's really not much traffic. I think it will really take a while until you get performance issues. \$\endgroup\$
    – Philipp
    Dec 27, 2012 at 17:34
  • \$\begingroup\$ I don't deny that. As I say, learning curve. I have now read up on pub/sub with redis which looks like it could do what I was saying. Main server for everything. Pub/sub. Game server to handle all the games - therefore allowing for multiple servers to be set up if required. \$\endgroup\$ Dec 27, 2012 at 20:06

1 Answer 1

2
\$\begingroup\$

General way to handle this is to allow multiple game servers to be spun up, and whenever a new game is started, one is chosen and the client is told to connect to that server. You can then add and remove game servers as necessary to scale horizontally, essentially limited by only by hardware/bandwidth capacities.

Scaling up the login servers can be done by using round-robin load-balancing on your servers, which can be achieved at the DNS level, or via a hardware load balancer (generally not cheap, though some data centers offer use of a shared load balancer for a price). The same can be done with the match making servers.

You can also deal with this per region. That is, your customers in China might be using a different set of servers in a Chinese data center while your customers in North America might be using a set of servers in a data center there. Or if NA is where most of your customers are, you can split up the data centers between the east and west halves of the continent.

Things get tricky when it comes to sharing data between your servers. In these cases, it is generally better to have a middle layer between the main game/logic servers and the backend storage. That is, don't have your game servers access a database to look up player information. Instead, create an internal API (using REST over HTTP, or an AMPQ infrastructure, or what have you) that servers use to communicate with backend services. The advantage of this approach is that it makes physically distributing your services easier. You might want those match making and game servers split between China and NA, but you might want all account information to be centralized so players in each region can friend each other and start direct matches with each other (of course one of the two players will be using a non-ideal game server for their location, but no way around that). With an API, you can have your Chinese data center game servers talk to a local API proxy that caches requests made to the "authoritative" servers in NA, allowing distributed operation with good horizontal scalability and a single primary data store for user accounts.

Keep in mind that you'll want to limit that as much as possible to infrequently changing data, since you'll need to do all writes to the primary data center to avoid collisions. That is, you can't share user accounts between a NA and a Chinese datacenter is both can create accounts locally, since two users might try to create a user account with the same name in both regions. Since you'll be forced to use one data center as the authoritative master for this data, that means creating accounts in other regions will be a tad bit slower. Account creation is generally not something that needs fast response times, so that's not a huge deal; if you're trying to track play stats for every move in your game, though, it might become an issue. For cases like that, you'll want to aim towards a data design that allows merging data later in bulk, rather than needing to keep a real-time data set in an authoritative server.

All that said, you probably don't need to worry too much. A simple turn-based board game style of thing is not going to be particularly data intensive, and your odds of getting lucky and being successful enough to have so many users that one server can't handle the load is pretty small.

\$\endgroup\$

You must log in to answer this question.

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