Design Chess Game

Meta's "Design Chess Game" interview question focuses on architecting a scalable online system for two-player chess matches. It emphasizes real-time gameplay, reliability, and handling massive user scale across relevant tags like system design and backend.

Problem Statement

Design a two-player online chess game that is fast, reliable, and supports 100 million monthly active users (MAU), each playing one game per week. The system must handle game creation, move validation, real-time updates, and termination while ensuring low latency and high availability.[1]

Functional Requirements

• Create a game: Pair two online players (using ranking/rating algorithms), assign white to start first, and direct them to the same board.
• Record player status: Store game info, moves, and stats like wins, losses, best/worst openings.
• Valid moves: Validate every move with accurate chess rules; no undos or cancellations allowed.
• Display moves: Broadcast each move instantly to both players.
• Game termination: Detect and enforce end states like checkmate, resignation, forfeit, or stalemate.[1]

Non-Functional Requirements

• Latency: Under 100 ms for smooth, responsive gameplay.
• Reliability: Fault-tolerant, with no downtime impact from partial failures.
• Scalability: Support 100M+ MAU (peak concurrent games estimated at thousands based on weekly play).
• Consistency: Game states must be accurate and up-to-date for all players.[1]

Input/Output Examples

No explicit I/O formats (e.g., JSON schemas or API payloads) are detailed in sources, as this is a system design question prioritizing architecture over code. Example flows include:

• Game creation API: Input: Player IDs, ratings → Output: Game ID, board assignment.
• Move submission: Input: Game ID, from/to positions → Output: Validated new board state, broadcast via WebSocket.
• Query game state: Input: Game ID → Output: Current board, move history, player turns.[2][1]

Constraints

• Scale: 100M MAU → ~400K daily games → handle bursts without degradation.
• Real-time: Strict ordering of moves; no race conditions.
• State management: Persist games durably but optimize for speed (e.g., no full history reloads).
• Edge cases: Disconnects (forfeit after timeout), cheating detection, mobile/web compatibility. No hard computational limits on chess rules (e.g., board size fixed at 8x8), but validation must be efficient.[2][1]