This is somewhat of a C# question, but it's related to PlayFab because it involves trying to work within PlayFab API limits.
Also note that this solution is on legacy matchmaking, not matchmaking v2, because matchmaking v2 does not support match size of 1.
I currently have a single-instance login queue for my game. It works something like follows:
- When a client connects --> add the client's connection id to a queue
- Every second --> pop a few connection ids off the queue and tell them that they can connect to the main lobby server
- Every second --> (Optional) tell each client which position # it is in the queue
This works fine, and because it's so lightweight, it will probably scale to at least a few thousand players. However, I'm thinking about preparing (or at least having a solution in mind if I have to scramble to implement it later) for the possibility of having a login queue larger than a few thousand players. This could be very realistic if the main lobby server crashes, or more commonly, we just release a new patch (and everyone is booted from the old patch and reconnects at the same time).
Thus, it might be needed to distribute the login queue across multiple instances. My concern with this is that I feel that in order for the PlayFab matchmaker to load balance, I will need the login server to call AuthenticateSessionTicket, RedeemMatchmakerTicket or PlayerJoined, and NotifyMatchmakerPlayerLeft in order for PlayFab's service to know how many players are currently connected to the login server. It needs to know how many players are currently connected to the login server in order to decide whether to spawn a new login server.
Having to make all these API calls will almost certainly risk having the login queue itself become throttled by PlayFab API limits, so then I would need to implement a queue just to enter the login queue, which sounds very complex and just seems like it's moving the problem rather than solving the original problem.
My current solution is just sticking with a single instance for now and hope for the best, but it'd be nice to have at least a theoretical solution in case we need to scale beyond a single login queue later.
