Hey everyone,
We’re working on a new game that requires a robust matchmaking strategy to handle large numbers of concurrent users. Here are our requirements:
- Matches can have anywhere from 1-20 users.
- Users should be able to either join an existing match or create their own.
- The matchmaking system should be able to scale to handle thousands of concurrent users.
After considering different options, we decided to use MatchListing (Find or create approach) instead of Nakama Matchmaker. (Mainly because we need backfilling & the ability to start match with a single player). This approach involves sending a “find_match” RPC request to the server whenever a user needs a match. We use Nakama match listing to see if there are any available slots in running matches, and if not, we create a new match and send the ID back to the user.
However, we discovered an issue where if two users try to find a match at the same time, they are allocated to different matches. We suspect this is due to a delay in registering matches by Nakama. Although we initially thought this behavior might be acceptable in production, recent load testing results suggest otherwise. The “delay in registering matches” is a significant issue whenever we have a spike in “find_match” requests, such as after a scheduled downtime.
We’re looking for recommendations on how to overcome this issue and make our matchmaking strategy more robust. Any insights or advice would be greatly appreciated!
Hi @gpaul-sumo;
I think MatchListing
is a better solution for what you’ve described as well.
we discovered an issue where if two users try to find a match at the same time, they are allocated to different matches.
This is most prevalent in synthetic benchmarking where you only concentrate on one aspect of the entire player experience where the only user requests are find_match
RPC. This skews the result quite significantly as in real-life scenarios there will be ongoing matches with existing online players and find_rpc
will not result in the same scenarios you’ve mentioned.
We suspect this is due to a delay in registering matches by Nakama.
The “delay in registering matches” is a significant issue whenever we have a spike in “find_match” requests, such as after a scheduled downtime.
There is no artificial delay in Nakama; This is just the consequence of having to lock certain memory parts for writes as in any concurrent system. You are only noticing this because you are hitting the system concentrated on this particular code path (any system would look the same).
In production projects that we’ve setup on infrastructure we power, we configure a rolling reboot and there is no need for “downtime” at all.
I suggest that we explore what a commercial support/deployment options look like so we can help you further with your benchmarking, production workload and deployment. Feel free to email me (mo@) and we can setup a call together to discuss the title in more details in private. Thanks!