Design a Matchmaking System

Design the object model and public APIs for the matchmaking core of an online competitive game: the classes that hold the pool of waiting players, track each player's skill rating, and repeatedly assemble balanced matches from whoever is currently queued. This is the in-process engine a game server would drive on a tick, not the network transport or the game session itself.

Operating context. Players (solo or in a small pre-formed party of up to five) join a queue for a given mode; each carries a skill rating and a rough latency region. On every tick the engine scans the waiting pool and forms matches of a fixed shape (e.g. two teams of five). A candidate match is only allowed if it satisfies a set of criteria — closeness of skill, compatible region, and roughly even teams. The longer a player or party waits, the more the skill tolerance should widen so nobody is stuck forever, and parties must stay intact on the same team. There is no clock you should read directly, no persistence, and a single thread drives the tick loop.

Out of scope. Network transport and lobby handoff, anti-cheat and account systems, the rating-update math after a match ends (assume a rating is given), server allocation / provisioning, and the concrete UI. Model the engine's object graph, not the wire protocol.

What to produce. The class hierarchy (Player, Party, the queue / waiting pool, a match candidate, the matched result, and the engine that ties them together), the public API each class exposes, and the lifecycle a ticket moves through while it waits. Be explicit about: how match criteria are pluggable and composable so a new rule can be added without editing the engine, how wait time widens the acceptable skill band, how a full match is balanced into fair teams while keeping every party whole, and how the design stays testable without a real clock.