Skip to content
System Designer

Medium · Games

Multiplayer matchmaking

Players press Play and wait. You must put them in a match with others nearby, with similar skill, in a few seconds. Players in a far-away region will have a bad time, so you must keep each region close. Practise this medium system design problem for free with a Google or GitHub account.

The brief

Players press Play and wait. You must put them in a match with others nearby, with similar skill, in a few seconds. Players in a far-away region will have a bad time, so you must keep each region close.

Think of finding a match in an online game.

Users, scale and requirements

Who uses it
3 million players online at peak
Audience in plain numbers
12,000,000 users or devices
Normal peak
≈ 12,000 requests per second
Request mix
Read: 55%; Write: 25%; Message: 20%
Speed for 99 of 100 requests
Read: ≈ 200 ms; Write: ≈ 200 ms; Message: ≈ 300 ms
Successful requests
99.9%
Data safety
Best effort: small losses are tolerated.
Monthly budget
≈ $32,000
Data at rest
≈ 0.5 TB
Where users are
North America: 40%; Europe: 35%; Asia Pacific: 25%
Home region
North America
Waiting deadlines
Read: 900 seconds; Write: 3,600 seconds; Message: 900 seconds

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

  • Each waiting player polls or holds a connection until matched (approx.).
  • Lobby messages are tiny, about 1 KB.

Questions that shape the design

How long may a player wait?

Most should be matched within 10 seconds. Being matched slowly beats being matched badly far away.

Can players play across regions?

Only when a region is empty or down. Normally keep them local: a ping above 80 ms feels bad.

Do we keep waiting tickets if a machine fails?

It is fine to lose waiting tickets. Players just press Play again.

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 17:00 · Overseas launch

    A launch brings users who are far from your servers.

    Affected share: 40%.

  2. 20:00 · Flash crowd

    A scheduled launch brings a sudden rush of requests.

    Traffic reaches 3 times the scheduled load; rises over 30 seconds, holds for 1,800 seconds and eases over 1,800 seconds.

  3. 21:30 · Zone outage

    An availability zone loses power or network access.

    Duration: ≈ 3,600 seconds.

What a strong design has to handle

  • Where should a player be matched: near them or in one big pool in one place?
  • Claim players into one compatible match while widening search predictably.
  • Waiting longer lets the matcher find a better skill match; matching instantly gives lopsided games.
  • Regional pools give low ping but small pools at night. You may widen the search over time.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

Related problems