Practice/Meta/Design DoorDash

Design DoorDash

Product DesignMust

Problem Statement

You've been asked to architect a matchmaking system for a popular online multiplayer game with millions of active players. The system needs to pair players together for matches based on skill level, geographical location, preferred game modes, and party composition. Players expect to find matches within seconds, and once matched, they need real-time communication about match status, lobby details, and game server assignments.

The system must handle peak loads of 500,000 concurrent users attempting to find matches, support various game modes (solo, duo, squad), and gracefully handle scenarios where players disconnect, decline matches, or experience network issues during the matchmaking process. The platform operates globally across multiple regions and must provide a fair, fast, and reliable experience that keeps players engaged.

Key Requirements

Functional

Player queueing -- Allow players to enter matchmaking queues with specified preferences (game mode, region, skill tier)
Skill-based matching -- Match players of similar skill levels using a rating system (ELO, MMR)
Party support -- Enable groups of friends to queue together and find appropriate opponents
Match confirmation -- Notify all matched players and handle accept/decline responses within a timeout window
Game server assignment -- Allocate and communicate game server details to confirmed players
Queue status updates -- Provide real-time feedback on queue position, estimated wait time, and match found notifications

Non-Functional

Scalability -- Support 500,000+ concurrent matchmaking requests with ability to scale during peak hours
Reliability -- Maintain 99.9% uptime with graceful degradation when components fail
Latency -- Provide sub-second queue updates and match players within 30-60 seconds for 95% of requests
Consistency -- Ensure no duplicate matchmaking, handle concurrent requests correctly, maintain accurate skill ratings

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Matchmaking Algorithm Design

The core challenge is efficiently pairing players with compatible attributes from a massive pool while balancing match quality with wait time. Interviewers want to see how you handle the tradeoff between perfect skill matches and acceptable wait times.

Hints to consider:

Consider bucket-based strategies that group players into skill tiers initially, then expand search radius over time
Think about how to handle edge cases like high-skill players who have few potential matches
Discuss data structures for fast lookups (priority queues, spatial indexes for region-based matching)
Address how party matchmaking affects the complexity (matching a party of 3 with another party or solo players)

2. Real-Time State Management and Communication

Players expect instant feedback throughout the matchmaking journey. The system must broadcast state changes to connected clients efficiently and handle network failures gracefully.

Hints to consider:

Evaluate WebSocket connections versus Server-Sent Events for maintaining live connections with players
Design a message queue architecture for broadcasting match found notifications to all participants simultaneously
Consider how to handle partial failures (some players receive notification, others don't)
Think about heartbeat mechanisms to detect disconnected players still in queue

3. Race Conditions and Concurrent Matchmaking

Multiple matchmaking services may attempt to place the same player in different matches simultaneously, or players may cancel queue while a match is being formed.

Hints to consider:

Use distributed locking or reservation systems to prevent double-matching
Design an idempotent match confirmation flow with clear state transitions
Consider eventual consistency tradeoffs when removing players from queues
Think about how to handle clock skew across distributed services making concurrent decisions

4. Geographic Distribution and Latency Optimization

Players around the world need fair matchmaking, but network latency to game servers significantly impacts gameplay quality.

Hints to consider:

Design a multi-region architecture where matchmaking happens regionally first
Consider how to handle sparse regions with fewer players (cross-region matching with latency limits)
Think about where to place matchmaking services relative to game servers and player populations
Discuss CDN-like strategies for distributing game server capacity

Practice/Meta/Design DoorDash

Design DoorDash

Product DesignMust

Problem Statement

Key Requirements

Functional

Player queueing -- Allow players to enter matchmaking queues with specified preferences (game mode, region, skill tier)
Skill-based matching -- Match players of similar skill levels using a rating system (ELO, MMR)
Party support -- Enable groups of friends to queue together and find appropriate opponents
Match confirmation -- Notify all matched players and handle accept/decline responses within a timeout window
Game server assignment -- Allocate and communicate game server details to confirmed players
Queue status updates -- Provide real-time feedback on queue position, estimated wait time, and match found notifications

Non-Functional

Scalability -- Support 500,000+ concurrent matchmaking requests with ability to scale during peak hours
Reliability -- Maintain 99.9% uptime with graceful degradation when components fail
Latency -- Provide sub-second queue updates and match players within 30-60 seconds for 95% of requests
Consistency -- Ensure no duplicate matchmaking, handle concurrent requests correctly, maintain accurate skill ratings

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Matchmaking Algorithm Design

Hints to consider:

Consider bucket-based strategies that group players into skill tiers initially, then expand search radius over time
Think about how to handle edge cases like high-skill players who have few potential matches
Discuss data structures for fast lookups (priority queues, spatial indexes for region-based matching)
Address how party matchmaking affects the complexity (matching a party of 3 with another party or solo players)

2. Real-Time State Management and Communication

Players expect instant feedback throughout the matchmaking journey. The system must broadcast state changes to connected clients efficiently and handle network failures gracefully.

Hints to consider:

Evaluate WebSocket connections versus Server-Sent Events for maintaining live connections with players
Design a message queue architecture for broadcasting match found notifications to all participants simultaneously
Consider how to handle partial failures (some players receive notification, others don't)
Think about heartbeat mechanisms to detect disconnected players still in queue

3. Race Conditions and Concurrent Matchmaking

Multiple matchmaking services may attempt to place the same player in different matches simultaneously, or players may cancel queue while a match is being formed.

Hints to consider:

Use distributed locking or reservation systems to prevent double-matching
Design an idempotent match confirmation flow with clear state transitions
Consider eventual consistency tradeoffs when removing players from queues
Think about how to handle clock skew across distributed services making concurrent decisions

4. Geographic Distribution and Latency Optimization

Players around the world need fair matchmaking, but network latency to game servers significantly impacts gameplay quality.

Hints to consider:

Design a multi-region architecture where matchmaking happens regionally first
Consider how to handle sparse regions with fewer players (cross-region matching with latency limits)
Think about where to place matchmaking services relative to game servers and player populations
Discuss CDN-like strategies for distributing game server capacity