Common Problems
Online Chess
Understanding the Problem
♟️ What is Chess.com / Lichess?
Online chess platforms let players find an opponent of similar skill, play a real-time game with a clock for each player, and climb a global rating leaderboard. The server validates every move and owns both clocks, so players can't simply tell it that an illegal move is valid or that they have more time left.
For this design, we'll support one format: three-minute blitz. Each player has three minutes total to make their moves, and their clock runs only during their turn. No extra time is added after a move. That gives every game the same rules for matchmaking and clocks.
Each player has a skill rating that rises when they win and falls when they lose. We use it to find opponents of similar skill and rank players on the leaderboard. We'll build a single game first, then use the deep dives for the parts that get hard at scale. That means matchmaking, running a large fleet of game servers, keeping the clock fair across different network latencies, and making leaderboard reads fast.
Functional Requirements
Start by nailing down the top few functional requirements. Everything else is below the line. Calling those out shows product sense, but you won't design them, so keep the core list tight and check with your interviewer before moving on.
Core Requirements
- Players should be able to find an opponent through skill-based matchmaking and start a game.
- Players should be able to play a game in real time.
- Players should be able to view a global leaderboard and see their own rank, both updating shortly after games finish.
Below the line (out of scope)
- Spectating live games and broadcasting popular boards.
- In-game chat, friends, and social features.
- Puzzles, training, and post-game analysis or replay.
- Tournaments and arena play.
- Anti-cheat and engine-detection (fair play), plus tournament integrity. We'll come back to why this one is interesting but out of scope at the end.
Non-Functional Requirements
Before the requirements, let's pin down the scale, since it drives most of the design. We'll design for 10M registered players and 500K concurrent games at peak. Each game has two players on their own connections, so that's 500K games * 2 = 1M concurrent connections, plus the compute to validate every move and run two clocks per game. These numbers carry through the deep dives.
With that in mind, here are the non-functional requirements:
The Set Up
Planning the Approach
Defining the Core Entities
API or System Interface
High-Level Design
1) Players should be able to find an opponent through skill-based matchmaking and start a game
2) Players should be able to play a game in real time
3) Players should be able to view a global leaderboard and see their own rank
Potential Deep Dives
1) How do we prevent a player from being matched into two games?
What if matchmaking outgrows Postgres?
2) How do we scale the game servers to 500K concurrent games?
3) How do we keep the clock fair despite uneven latency?
4) How do we keep the leaderboard correct and fast at 10M players?
Final Design
Some additional deep dives you might consider
What is Expected at Each Level?
Mid-level
Senior
Staff+
Purchase Premium to Keep Reading
Unlock this article and so much more with Hello Interview Premium