The architecture of the service is similar to that of any other AcceleratXR Core micro-service. The service is implemented as a stateless HTTP server that uses a database to store all Ticket and Match information. This allows the service to be scaled infinitely to meet any amount of demand and enabling any single micro-service instance the ability to respond to requests for any ticket managed by the system.

The processing of tickets is deferred to a specalized program called a Ticket Processor. The role of the ticket processor is to perform the primary work of searching for and creating matches. Traditional matchmaking systems often utilize a bucket system that separates tickets into groups of similar criteria. Each bucket is processed by one single-threaded program which performs a loop to collate and create matches for all tickets in the bucket. The performance is particularly slow, often being O(n^2) in the best case. As the search criteria for a given user expands their tickets are moved from bucket to bucket. This creates a common problem where two perfectly matched tickets may never be matched together as they are never in the same bucket at the same time. This age old architecture is why most games take several minutes to find a match for any given player.

Our matchmaking system takes a very different approach. Each ticket is processed individually within it’s own separate Ticket Processor process. The processor filters only the best suited matches for a given ticket from the entire database. Once a selection of tickets is found, a fitness score is computed for each ticket corresponding to the closeness of the searching ticket. These scores are then ranked from best fit to least fit. Finally, the program attempts to create the match with the top selection of required tickets. Should any of the selected tickets have already been claimed by another match the process is started over after a brief sleep period.

This approach is made possible by exploiting the transactional atomicity of certain databases. More specifically, this system utilizes the Redis database and its native Transactions support in order to gaurantee atomic locking during match creation. What this means in practice is that while a single ticket may fail to successfully create a match on its own there is a high probability that another ticket will successfully match that same ticket in another process.

This important breakthrough in matchmaking architecture has two primary benefits. First, it eliminates the arbitrary segregation of user population that makes matchmaking difficult in low CCU scenarios. Second, it dramatically decreases the processing time needed to find matches by utilizing the full parallel processing power of cloud computing. The net result is a system that can match hundreds of thousands of users (and more) from a single global pool in seconds rather than minutes.