Matchmaking queues: wait time vs match fairness, an interactive simulator

A matchmaker trades two things players care about: how long they wait and how even the match is. Requiring close ratings makes fair games but leaves players far from the average, the very good and the new, waiting for opponents who rarely come. Accepting anyone makes instant, lopsided games. The common answer is a window that starts narrow and widens the longer a player waits.

The playground runs fifteen minutes of a one-versus-one queue with Elo-style ratings. Compare the three windows at a busy time and at 3 a.m., and click one to see who waited.

Fair, fast, or both

With a player arriving every second, a strict 50-point window gives near-even games, the underdog winning about 47% of the time. But the players who give up are all far from the middle of the rating curve, and 1 in 20 matched players waits half a minute or more. A fixed 400-point window matches almost everyone within seconds, at an average gap of 171 points: the underdog wins only 29%. Widening from 50 points by 20 a second keeps most games close, the underdog winning 42%, while nobody waits long.

At 3 a.m., with a player every ten seconds, the strict window loses 28% of players to the queue. Widening still matches almost everyone, but the games are less even: when the population is thin, the honest choice is between waiting and fairness, and the window decides how much of each.

Ratings and real matchmakers

• Elo predicts a 400-point favourite wins 10 times in 11 and moves both ratings after each game by how surprising the result was. Glicko and TrueSkill add an uncertainty per player, so new players’ ratings move fast and settle as evidence grows.
• More than rating: real matchmakers also weigh latency to the server region, party size and team balance, and sometimes recent losing streaks.
• Batching: instead of matching greedily as players arrive, many collect a pool every few seconds and solve for the best overall pairing, which leaves fewer stranded outliers.
• Scale: queues are partitioned by game mode and region, and players are bucketed by rating so the search for a partner checks nearby buckets, not the whole queue.

Elo and an expanding window in code

def expected(r_a, r_b):
    """Chance that a player rated r_a beats one rated r_b."""
    return 1 / (1 + 10 ** ((r_b - r_a) / 400))

def elo_update(r_a, r_b, a_won, k=32):
    e = expected(r_a, r_b)
    s = 1.0 if a_won else 0.0
    return r_a + k * (s - e), r_b + k * ((1 - s) - (1 - e))

def window(waited_s, start=50, per_s=20, cap=400):
    """How far apart in rating a player will accept, after waiting this long."""
    return min(cap, start + per_s * waited_s)

def can_match(a, b, now):
    gap = abs(a.rating - b.rating)
    return gap <= window(now - a.joined) and gap <= window(now - b.joined)

In a system design interview

For a matchmaking service, describe the queue and the trade-off: “Players enter a queue partitioned by mode and region and bucketed by rating. Every second a matcher scans each bucket and its neighbours, pairing players whose rating gap fits both of their windows; windows start at 50 points and widen with wait time, so p95 wait stays under 30 seconds even off-peak. Ratings use Glicko-2 and are updated by a consumer of game results.” Expect the follow-ups: what happens when a matched player does not accept, how to avoid two matchers grabbing the same player, and smurf accounts.

Read the guide to matchmaking and skill rating or multiplayer game servers, see fair queuing for another kind of waiting-line trade-off, or watch a strong candidate design a matchmaking service.

Questions people ask