# Design a Real-Time Player Matchmaking Service ### Prompt Design a service through which a player can join a matchmaking queue, cancel a pending request, be paired with a compatible player, and receive a notification when a match is ready. Requests must also expire, and the design must handle a player disconnecting while queued or while a match is being finalized. Explain the public API, request lifecycle, storage model, matching workflow, and failure behavior. The compatibility policy itself can be treated as a configurable predicate over player attributes. **Candidate hint:** Start with the state transitions for one matchmaking request, then decide which transitions require coordination when multiple workers act concurrently. ### Constraints & Assumptions - A player may have at most one active matchmaking request. - A player must never be committed to two matches at once. - Join, cancel, timeout, and match-finalization operations may race. - Notifications can be retried and therefore may be delivered more than once. - State any assumptions about scale, acceptable wait time, regional placement, and compatibility widening. ### Clarifying Questions to Ask - Must both players explicitly accept, or is a server-side match immediately final? - How fresh must presence and disconnect information be? - Can a request move between compatibility pools as it ages? - Is cross-region matching allowed, and what latency trade-off is acceptable? ### What a Strong Answer Covers - A precise request and match state machine with safe concurrent transitions - Queue organization, compatibility lookup, fairness, and horizontal partitioning - Idempotent APIs and a clear resolution of cancel-versus-match races - Reliable player notification without confusing delivery with durable match state - Expiration, disconnect handling, observability, and recovery from worker or storage failure - Explicit consistency, availability, and latency trade-offs ### Follow-up Questions 1. How would you prevent a popular compatibility pool from starving a smaller one? 2. What changes if players must accept a proposed match within ten seconds? 3. How would you recover requests owned by a matcher that crashes mid-operation? 4. How would you support gradual compatibility widening without repeatedly re-enqueuing every request?