Design a Fault-Tolerant Online Chess Service

## Prompt Design an online chess service that supports creating a game, submitting moves, maintaining player clocks, determining game completion, reconnecting clients, and recovering from server failure. Explore a stateless application tier while preserving one authoritative move order. ### Constraints & Assumptions - Two authenticated players participate in one game; spectators may read with delay. - Moves must be validated against the exact preceding game version. - The server is authoritative for clock time and final result. - A retry after a timeout must not append the same move twice. ### Clarifying Questions to Ask - Which chess variants, time controls, and draw rules are in scope? - How quickly must a reconnecting player see authoritative state? - Can games tolerate a short pause during failover, or must move acceptance remain available? ```hint Store clock anchors Persist remaining time and the timestamp at which the active player's turn began; derive the current clock on demand. ``` ```hint Version every move A move should name the expected game version and an idempotency key so two workers cannot both accept the next move. ``` ### What a Strong Answer Covers - APIs and data model for game state, ordered moves, versions, clocks, and outcomes. - Atomic move validation and idempotency under concurrent or retried submissions. - Server-clock calculations that do not require a per-game ticking process. - Stateless read/write workers backed by an authoritative per-game serialization mechanism. - Reconnect, fault tolerance, event delivery, cheating boundaries, and observability. ### Follow-up Questions 1. How would you support a high-volume tournament with many spectators? 2. What happens if a move and flag-fall are observed at nearly the same time? 3. How would you audit a disputed result without retaining every websocket message?