Katkat
Back

Design a Real-Time Player Matchmaking Service

WaymoSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests the ability to design a distributed, low-latency matchmaking system capable of handling concurrent requests, state consistency, and efficient participant matching.

System Design: Real-Time Matchmaking Service

Design a global matchmaking service for a competitive multiplayer game. The system must group players into matches based on predefined criteria (e.g., skill level, latency, game mode).

Functional Requirements

  1. Join Queue: Players submit a request with their skill rating and regional preference.
  2. Cancel/Timeout: Players can cancel, or requests automatically expire after a period.
  3. Matching: The system must pair two compatible players and guarantee that a player is never matched twice simultaneously.
  4. Notification: Once a match is formed, both players must be notified immediately.

Non-Functional Requirements

  1. Low Latency: Matching decisions should ideally happen within seconds.
  2. Scalability: The system must support thousands of concurrent players across different regions.
  3. Consistency: Ensure no race conditions occur where a player is assigned to two matches, or a canceled request results in a match.
  4. Resiliency: The system must handle worker process crashes without losing player queue data.

Deliverables

  • Define the high-level system architecture and API endpoints.
  • Explain how you would store the matchmaking state (e.g., Redis, database, in-memory).
  • Describe the matching algorithm logic (e.g., how to handle skill rating expansion over time).
  • Explain how to handle concurrency and worker failures to ensure a player is only matched once.

Hints

Hint 1

Consider using a distributed key-value store with atomic operations or distributed locks to manage the matchmaking queue state.

Hint 2

Think about using 'bucketizing' players based on skill tiers to limit the search space for potential matches.

Hint 3

For fault tolerance, consider using a message queue or a persistent state store to track a player's journey from 'in-queue' to 'matched'.

Follow-up questions

  • How would you adjust your matching logic if a player's skill rating range must expand the longer they stay in the queue?
  • If the matching service becomes a bottleneck, how would you partition or shard the matchmaking requests?
  • How do you handle the 'cancel' request if the matching engine has already selected the player but hasn't finalized the notification yet?