Advertisement Jump to content
Sign in to follow this  

How to scale a multiplayer card game?

This topic is 1194 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working on an online card game. We use a simple client-server architecture. Each game involves the player being matched with another user (or the computer AI) and then the game runs until someone wins or concedes, usually 5-10 minutes. Currently we run a single game server.


I'd like to know how I can scale the system to accommodate more players in the future. My initial thought was to have a front edge server to perform load balancing, matchmaking and security functions, which sends player updates to the appropriate server and evenly distributes the players across the servers. As we run additional servers, they will register with the front edge server. Is there commercial or open source software that already does something like this? Currently, the servers are i/o bound with a large number of players but I'm concerned that in the future, it will be network traffic on the front edge server that will be the bottleneck. Is there a way to hand-off the network traffic to a server once the players are matched? What other architectures should I consider?


Many thanks in advance. I realize that there isn't a lot of data here but would appreciate any pointers and ideas.

Share this post

Link to post
Share on other sites
Are there commercial or open source load balancers? Yes.
Try haproxy for an open source package.
Try any modern ingress router with DNAT for commercial hardware.
Also, typically it's the load balancer that does liveness check on the app servers, rather than the other way around, by making some null request every few seconds.

My main question to you is what your game state looks like, and what your communications looks like.
If game state can be persistently stored between game turns, then each request can be stateless. The serving app server would just slurp in the game state, perform the action, and store the new game state back. This would work very well with existing HTTP scalability infrastructure.
Almost any database should be able to keep those games in RAM for fast access. Or go with something that's explicitly RAM-based, such as Redis.
You'd want long-term data (like rankings/scoring/winnings/etc) to live in a more traditional disk-based relational database though.

Finally -- how come you are I/O bound? Your workload does not sound to me like it should be like that. Probably, something is tuned or implemented unwell...

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!