Katkat
Back

Design Online Chess Matchmaking

OpenAISoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests the ability to design a distributed, low-latency matchmaking system that balances player skill (MMR), wait time, and network latency under high concurrency.

Design an Online Chess Matchmaking Service

Design a backend service that pairs players for 1v1 chess matches. The system must support millions of concurrent users and provide matches with low wait times while ensuring high-quality, fair pairings.

Functional Requirements

  1. Players can join a matchmaking pool with their current Elo rating.
  2. The system should prioritize finding an opponent with a similar skill level.
  3. The search criteria should widen over time (e.g., allow a wider Elo gap as wait time increases).
  4. Players can cancel their matchmaking request.

Non-Functional Requirements

  1. Low latency: Matches should be formed as quickly as possible.
  2. High availability: The system must remain operational if a specific matchmaking node fails.
  3. Scalability: The system should handle spikes in traffic (e.g., tournament days).
  4. Fairness: Prevent systematic abuse where players repeatedly dodge opponents.

Deliverables

  1. API Design: Define the primary endpoints for joining and leaving the pool.
  2. Architecture: Describe the service components (e.g., how to partition the pool, where to maintain state).
  3. Matchmaking Logic: Explain how you handle the widening search criteria (dynamic tolerance).
  4. Data Storage: Propose a storage strategy for player state and active search requests.

Example Scenarios

  • If a player with 1500 Elo waits for 10 seconds, the system might only accept opponents in the 1480-1520 range. At 30 seconds, this range might expand to 1400-1600.
  • Ensure that if a player loses connection, the match request is gracefully removed from the pool.

Hints

Hint 1

Consider using a sharded approach based on player Elo ranges to limit the search space for any single worker node.

Hint 2

Use a Redis-based sorted set or a similar structure to efficiently find players within a specific score range.

Hint 3

Implement a 'ticket' or 'request' object that tracks the start time of the search to allow the matchmaking algorithm to dynamically adjust its tolerance threshold.

Follow-up questions

  • How would you handle race conditions where a player is matched simultaneously by two different matchmaking nodes?
  • How does your system guarantee that a player's search criteria update is reflected immediately if they have been in the queue for a long time?
  • What metrics would you monitor to detect if the matchmaking system is degrading in performance or fairness?