Matchmaker
A matchmaker is the service that groups waiting players into matches and requests a game server for each one. It weighs rules such as latency, skill, party size and time spent waiting, then decides when a group is good enough to start, relaxing its rules the longer players wait. Most of its decisions trade match quality against queue time.
Also called
matchmaking, matchmaking system, game matchmaker
,
How Is a Matchmaker Structured?
Most matchmakers are built around the same loop. Players don't join a match directly. They join a queue, and the matchmaker keeps reading that queue until it finds groups that fit together.
A player or a party asks to play. Friends usually gather in a lobby first, then queue as one group so they land on the same team and server.
The request becomes a ticket. A ticket carries what the rules need: game mode, party size, a skill rating, ping to nearby server locations, and anything else the game matches on.
The ticket enters a queue. Each queue, often one per mode or playlist, has its own rules. Players in different queues never meet.
The matchmaker evaluates the queue, pass after pass. On each pass it looks for tickets that satisfy every rule at once. Tickets that don't fit wait for the next pass, and their rules loosen as they age.
A match forms, and a server is requested. The matchmaker hands the group off. Which server hosts it, and where, is server allocation.
Players learn where to connect. Clients usually check their ticket's status (searching, match found, server assigned or cancelled) every few seconds, and connect once they have an address.
That loop is logic, and logic needs compute. Each pass checks waiting tickets against every rule, so a matchmaker runs on servers of its own, separate from the game servers, and its load grows with the number of players and the complexity of its rules.
Two details separate a working matchmaker from a prototype. Tickets expire, so a player who waits too long gets a clear "no match found" instead of an endless queue. And clients keep their ticket and assignment IDs, so a crash or a dropped connection doesn't send a player back to the end of the line.
Some games add one more step, where every player accepts the match before it starts. It confirms everyone is present, at the cost of a slower start and a chance to dodge a match a player doesn't like.
In Practices - Insights from Edgegap's Blog
Article's key insights
Region selection is a player complaint, not a feature request: When players ask to pick their server region, they are reporting a latency problem they cannot see or control. The feature they request is one possible answer, and on a smaller playerbase it trades bad matches for unfilled ones.
Latency-based grouping solves the issue that region locking attempts to mitigate: Regions are administrative boundaries. Latency is measured. Grouping players by measured ping keeps distant players out of the same lobby without partitioning the queue by geography.
Relaxing rules over time is the lever most matchmakers underuse: Activision's published research loosens skill constraints faster than connection constraints as queue time grows. The same graduated approach applies to any pooling rule.
Queue time is negotiable when the tradeoff is visible: Players in several communities volunteer to wait longer for better connection or a more filled match. The waiting is not what frustrates them. Not knowing what it buys them is.
Transparency and agency shorten the feedback loop: A visible ping figure and an opt-in to wait for a closer server turn vague blame into something a player can act on, at the cost of exposing numbers you may not want exposed.
What Rules Does a Matchmaker Use?
A rule is a test that every ticket in a match must pass. Most matchmakers combine a few kinds:
Player count. The number of teams, and the minimum and maximum players per team. A match can start at the maximum straight away, or at the minimum once players have waited long enough.
Exact match. Values that must be identical, such as the game mode or the game version.
Numeric difference. How far apart two values can be. Skill is the common case: skill-based matchmaking is a rule of this kind, and the rating behind it is covered under MMR and ELO matchmaking.
Latency. A maximum ping to the server's location, and often a maximum gap in ping between players. Measurements usually come from ping beacons. How latency relates to server regions has its own page.
Overlap. Values players share from a list, such as the maps everyone is willing to play.
The rules apply together, so each one narrows the pool. A match needs players who pass the skill test, the latency test and the mode test at the same time.
Rule relaxation is how a matchmaker handles the wait. Each ticket's rules loosen on a timer that starts when it enters the queue: for example, a wider skill range after 30 seconds, a higher latency limit after a minute, and a smaller minimum team after a few minutes. Relaxation is the dial between match quality and queue time. Where it starts and how fast it turns are design decisions for each game and mode.
Parties add a constraint of their own. A party fits a team only if the whole party fits, and its members' ratings are usually combined into one value, such as an average.
Every extra queue splits the pool again. A new mode, a platform filter or a region choice leaves each queue fewer players to match, a trade crossplay and session fill rate come back to.
What Does It Take to Build a Matchmaker?
Building a matchmaker is development work, and its problems are well known. The rules are game design. Most of the rest is engineering a team can solve with time. These practices, from our matchmaking documentation, hold for most matchmakers:
Separate development and production. Test rule changes on their own matchmaker, not on the live queue.
Use short ticket expiry while testing. Around 30 seconds rather than minutes, so a failed match shows up quickly.
Validate the configuration before it ships. One malformed rule can stop every match from forming.
Load test the way players behave. Ramp up gradually, retry with growing gaps, stop polling once a server is assigned, and model a daily peak rather than a flat load. Synchronized requests and instant retries test a pattern real players don't create.
Retry with backoff. Clients that wait a little longer after each failed request, with some randomness, and respect rate-limit responses (HTTP 429) avoid losing players during bursts.
Keep sensitive data on the server side. Skill ratings and cheat flags should come from the game's backend, not from a client that could change them.
Trace every match. Tagging each match and server with the tickets that formed it lets support find the logs behind one player's report.
None of this is unusual, and a team that builds its own matchmaker can work through it. The harder part often starts after launch.
What Does It Take to Run a Matchmaker in Production?
A matchmaker is a service that runs around the clock. If it stops, nobody gets into a match, however healthy the game servers are. That makes running it a different job from building it: someone has to be responsible for it at every hour players are online, in every time zone the game is sold in.
The operating work tends to include:
Redundancy. Several copies of the matchmaker, ideally in different regions, so one outage doesn't stop matches everywhere. Our documentation describes rotating copies as a blue/green setup.
Updates in step with the game. A new server build often needs a new client, and the new client needs a matchmaker pointed at the right version. A client release can take 3 to 7 days to reach players (Edgegap documentation, October 2026), so old and new versions overlap and both have to keep matching.
Capacity. Load grows with players, with how often clients check their status, and with rule complexity. Relaxation and overlap rules are among the most expensive to evaluate. The service has to be sized for launch day and live events, not the average day.
Tuning that doesn't end. Player counts change by season, region and hour, and rules that fit launch rarely fit the second year.
This is the human side of matchmaking, and the part that's hardest to staff. A self-built, self-hosted matchmaker means the studio owns all of it, at every hour. A managed matchmaker, such as Edgegap's, runs the service, its redundancy and its scaling, and leaves the rules with the studio.
A word from our sponsor (ourselves!)
Every empty player slot is capacity you pay for and nobody uses. One studio on Edgegap's matchmaker averaged 91% of player slots filled across its sessions in Q2 2025, so fewer servers carried the same players.
How Does Matchmaking Affect Game Server Hosting Costs?
Every match a matchmaker starts is a server someone pays for, full or not. Session fill rate, the share of a server's player slots actually in use over a match, links the matchmaker's rules to the hosting bill:
active sessions = concurrent players ÷ (players per session × fill rate)
Lower fill means more servers for the same players. In our cost model of a 10,000 peak CCU shooter (8 players per match, 1 vCPU per server, hybrid hosting), running at 50% fill cost $95,436 a year more than running at 95% (How Session Fill Rate Affects Your Multiplayer Hosting Costs, May 2026; a modelled estimate, not a measurement). The same article reports one regional deployment of an anonymized PvP game running at about 35% fill, at roughly three times the cost per player of its main market. The global average hid it.
Fill usually drops for reasons that each look sensible on their own: starting matches at the minimum player count, short timeouts that favour speed, too many modes splitting the pool, and small regions. The levers sit in the rules described above:
separate minimum and maximum team sizes
relaxation that loosens skill before latency
backfill for seats that empty mid-match
separate profiles for off-peak hours and quiet regions
fill rate tracked per region, not only globally
Our guide to optimizing session fill rate in your matchmaker covers each one.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Own the Rules, Not the Uptime
The part of matchmaking that makes a game better is the rules: who plays with whom, how long they wait, and how full each server runs. Those rules shape the player experience and, through fill rate, a large share of the hosting bill. They deserve a team's best hours.
Keeping the service up at every hour is different work. It matters just as much, but it doesn't make a match fairer or a server fuller. Before building and hosting your own matchmaker, weigh the hours it will take each month against what the same hours would return if spent on tuning.
A place to start: check fill rate per region and per queue every week. Where one sits well below the rest, change its rules before adding servers. One studio using our matchmaker averaged a 91% session fill rate in Q2 2025 (platform data), a single title rather than a platform average. Edgegap's matchmaker keeps the service running, so a team's time goes to the rules.
,
