Dynamic Matchmaker Shard Scaling for Game Queue Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud-based matchmaking services face processing capacity limitations when handling high traffic or complex matchmaking rules, leading to increased wait times for players as the processing needs of the matchmaking software exceed the capacity of a single host, resulting in a growing queue of requests.
Innovation Solution
Implementing a dynamic shard count system where matchmaking requests are distributed across multiple matchmaker shards, each potentially running on a different host, and adjusting the shard count based on metrics such as maximum wait time and algorithm utilization to ensure sufficient processing capacity while minimizing player population fragmentation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If matchmaking software is hosted on a single host, then device complexity is reduced and ease of operation is improved, but processing capacity is insufficient when traffic spikes or matchmaking rules become complicated, leading to increased wait times
Solution Approach 1:
The matchmaking software is divided into multiple independent shards that can be distributed across different hosts. Each shard handles a portion of the matchmaking workload, allowing the system to scale horizontally by adding more shards as traffic increases or matchmaking rules become more complex.
Solution Approach 2:
The system transitions from a single-host architecture to a multi-host distributed architecture, adding the dimension of spatial distribution across multiple machines. This enables the system to handle larger workloads by utilizing additional computing resources across the network.
2Productivity
If the number of matchmaker shards is increased to handle high traffic, then processing capacity and productivity are improved, but player population fragmentation increases which may affect match quality
Solution Approach 1:
The shard count is made dynamic rather than static, allowing the system to adjust the number of active shards based on real-time metrics such as traffic volume, algorithm utilization, and player population distribution. This enables the system to optimize between processing capacity and population stability by scaling shards up during high traffic and consolidating during low traffic periods.
Solution Approach 2:
The system implements feedback mechanisms that monitor metrics including maximum wait time, algorithm utilization, and player distribution across shards. Based on this feedback, the system automatically adjusts the shard count to maintain optimal performance while minimizing population fragmentation.
3Loss of time
If dynamic adjustment of shard count is implemented, then wait times are reduced and processing capacity is optimized, but system complexity and control difficulty increase
Solution Approach 1:
The system implements self-service automation where the shard count is adjusted automatically based on monitored metrics without requiring manual intervention. The system monitors its own performance and makes autonomous decisions about scaling shards up or down, reducing operational complexity despite the dynamic nature of the adjustment.
Solution Approach 2:
The system changes operational parameters (shard count) dynamically based on monitored conditions. By establishing predefined thresholds for metrics such as wait time and algorithm utilization, the system can automatically adjust the shard count parameter to respond to changing traffic patterns and maintain optimal performance.
Data Source
AI summary
A matchmaker (e.g., matchmaking software) may be implemented as a number of matchmaker shards, where each shard can potentially run on a different host within a service provider network. Disclosed herein are techniques and systems for dynamically adjusting a shard count associated with a given matchmaker of a subscriber during runtime, the shard count dictating a number of matchmaker shards used for assigning players to matches of a game. Adjustment of the shard count may be based on metrics that are usable to determine whether the current number of matchmaker shards is/are “overloaded”, and, if so, the shard count can be increased, or whether the current number of matchmaker shards are “underloaded”, and, if so, the shard count can be decreased.