Design the backend for online chess games with skill-based matchmaking and authoritative countdown clocks. Players enter a queue for a selected time control. The system pairs compatible opponents, creates a game, accepts legal moves, and shows both players clocks that continue to behave correctly through retries, disconnects, and reconnects. A game must end once a clock expires even if one client stops sending requests. ### Constraints & Assumptions - The server, not either client, is authoritative for moves and remaining time. - Duplicate move submissions must not apply a move twice. - Match quality may be traded for queue time according to an explicit policy. - Define how network delay is treated; do not silently trust a client timestamp. ### Clarifying Questions to Ask - Which time controls and per-move increments are supported? - Can a player be queued in more than one pool? - What latency and regional pairing trade-offs are acceptable? ```hint Store clock state as facts You do not need to decrement a database field every second. Consider the last accepted move time and the remaining durations at that transition. ``` ### What a Strong Answer Covers - Queue partitioning, widening rating ranges, atomic pairing, and cancellation races. - A versioned game state machine with legal-move validation and idempotent commands. - Server-side clock calculations, timeout scheduling, reconnect snapshots, and conflict handling. - Persistence, fan-out to both clients, observability, and recovery after process failure. ### Follow-up Questions - How would you prevent two matchmakers from pairing the same player? - What happens when a move and a timeout fire concurrently? - How would spectators receive updates without affecting the game path?