Design Online Chess Game

Design a Chess.com-Style Online Chess Platform
System Design · Real-time Matchmaking · Authoritative Game State

A platform like chess.com pairs two players quickly, places them in a shared game room, keeps both clients in sync on the same board, and enforces a strict clock. From the user’s perspective, the product feels like a lightweight realtime application, but the backend must remain the single source of truth for three essential facts: the final match result, the legal sequence of plies, and which player’s clock is active.

The players should experience a single shared board, but only the server may decide who was paired, which legal move happened next, and whose time was actually consumed. If those guarantees diverge, the product stops being chess and becomes two disconnected animations.

During clarification, define the time control early. Whether a mode uses increment or not changes both queue segmentation and how the server accounts for clock time after each accepted move.

Functional Requirements

• A player selects a supported time control and may enter or leave the matchmaking queue for that mode.
• The system pairs compatible queued players, creates a game, assigns colors, and connects both participants to the same live game session.
• Players can submit candidate moves; before accepting a ply, the server validates turn order and move legality.
• The server maintains authoritative remaining time for each side, applies increment when configured, and ends the game on timeout when a player’s clock reaches zero.
• Players can reconnect to an active game, recover the canonical board and clock state, and complete the match with a durable result that can feed downstream rating updates.

Non-Functional Requirements

• The server is authoritative for match outcome, ply sequence, legal board state, and clock accounting.
• A single ply can never be committed with two conflicting next moves.
• Target 99.95% availability for matchmaking, move submission, and canonical game-state reads within a healthy region.
• Target p95 < 250 ms for normal matchmaking in a healthy pool.
• Target p95 < 150 ms for move acknowledgement within a region.
• Target p95 < 1 s for opponent-visible updates after a committed move.
• Sizing assumes roughly 3M daily active players and 150k peak concurrent live games.
• Peak load planning uses 5k/s queue entries and 20k/s move submissions.
• After a move or terminal result is acknowledged, the ply order, remaining clocks at that boundary, and the final outcome must survive crash or failover.
• The client-side countdown display is cosmetic only.
• Retries or reconnects must not increase server-owned remaining time.
• Timeout decisions are based on server time.
• Only the two matched participants may submit moves or join private game channels; authentication and rate limiting are assumed at a high level.

Back-of-the-Envelope Estimates

Treat these numbers as coarse capacity anchors. They motivate keeping short-lived matchmaking tickets separate from durable game state, and they show that one writer per game can remain the right shape at peak move volume.

Out of Scope

High-Level Architecture — Matchmaking Pipeline and Authoritative Game Server

• Spectator mode, streaming, and public game feeds.
• Engine analysis, puzzles, move suggestions, and opening explorer features.
• Tournaments, team matches, clubs, and multi-board formats.
• Full anti-cheat or fair-play investigation pipelines beyond a short follow-up mention.
• Social chat, friends, notifications, and monetization features.