Matchmaking and skill rating
How online games and other two-sided systems pair people: skill ratings with Elo, Glicko and TrueSkill, matchmaking pools and widening search windows, the trade-off between match quality and wait time, regions and latency, parties, and scaling the matchmaker.
Reading is half of it. See this used in a real interview: walk through Design a Matchmaking System →
Matchmaking puts the right people together quickly: players of similar skill in a game, compatible people in a dating app, a customer and a suitable contractor. The core tension is the same everywhere: better matches require waiting for the right candidate, while players leave if they wait too long. A good design has a clear rating system, a pool-based matcher that relaxes its criteria over time, and an architecture that scales by region and mode.
Skill ratings
| System | Idea | Notes |
|---|---|---|
| Elo | each player has one number; after a game, ratings move by the difference between expected and actual results | simple; slow for new players; built for one-on-one |
| Glicko and Glicko-2 | a rating plus an uncertainty (deviation) | new or returning players move quickly while uncertain |
| TrueSkill and similar | Bayesian skill and uncertainty, supports teams and many players | used by large multiplayer games |
| Hidden MMR plus visible ranks | a hidden matchmaking rating with a separate displayed rank | lets the game present progression independently of the matching number |
Ratings update after each match from the result, often asynchronously from a match-result event. Store current ratings per player per mode (skill in one mode says little about another).
The matchmaking loop
- A player (or party) enters a queue for a mode and region, with their rating and connection details.
- The matchmaker repeatedly scans waiting tickets, looking for groups that satisfy the rules: rating within a window, team balance, latency, mode settings.
- When a match is found, the tickets are removed atomically, a game server is allocated, and players are told where to connect.
- If a player fails to accept or connect, the others return to the queue with priority.
Quality versus wait time
The trick is a widening window: start by matching only players within a narrow rating range; every few seconds, widen the acceptable range (and latency limit). Popular brackets match quickly with tight windows; rare ones (very high skill, unusual hours, small regions) eventually match with wider ones. Tune with data: track match quality (rating spread, predicted win probability near 50 %) and time to match by bracket.
Teams and parties
- Parties queue as one ticket; the matchmaker uses an aggregate rating (average, or weighted toward the best player) and prefers matching parties against parties.
- Team balancing assigns players so predicted win probability is close to even.
- Role-based games add constraints (one healer, one tank), which makes the search harder and usually needs a heuristic rather than an exhaustive search.
Latency and regions
Players must be on a nearby game server. Clients measure ping to regional data centres; tickets carry acceptable regions. Matchmaking usually runs per region and mode, which partitions the problem naturally. Cross-region matching is allowed only as a fallback when wait times grow. See multi-region architecture.
Scaling the matchmaker
- Partition by mode and region: each partition has its own pool, often held in memory on one matcher process for fast scanning. See sharding and partitioning.
- Keep a pool sorted by rating (a sorted set or tree) so searching within a window is a range scan, not a full scan.
- For very large pools, split into rating buckets with overlap, or run matching in short batches (every second) rather than per ticket.
- Use a single writer per pool to avoid two matchers claiming the same player; or claim tickets with atomic compare-and-set. See distributed locks and leases.
- Game server allocation: a fleet of servers per region that scales with demand, with warm capacity for peaks. See autoscaling.
Beyond games
- Dating: candidates are filtered by preferences and distance, then ranked by predicted mutual interest; "matching" happens when both swipe right. See Design Tinder.
- Marketplaces: a job is offered to suitable providers ranked by skill, rating, distance and availability, often with a timeout before trying the next. See Design Contractor Matching.
In the interview
For Design Matchmaking: a rating system with uncertainty, queues per region and mode, an in-memory matcher with sorted pools and widening windows, atomic ticket claiming, game server allocation, and metrics for match quality and wait time.
Checklist
- Ratings with uncertainty, per mode, updated from match results.
- Queues partitioned by region and mode.
- Widening rating and latency windows over time.
- Parties, team balance and role constraints.
- Sorted in-memory pools, single writer or atomic claims.
- Game server allocation and metrics for quality versus wait.