Limited Time Offer:Up to 0% off Hello Interview Premium
Up to 0% off Hello Interview Premium 🎉
Hello Interview
Learn System Design
Introduction
How to Prepare
Delivery Framework
Core Concepts
Key Technologies
Common Patterns
Question Breakdowns
Networking Essentials
API Design
Data Modeling
Caching
Sharding
Consistent Hashing
CAP Theorem
Database Indexing
Numbers to Know
Bitly
Dropbox
Local Delivery Service
Ticketmaster
FB News Feed
Tinder
LeetCode
WhatsApp
Rate Limiter
YouTube
FB Live Comments
YouTube Top K
Uber
Web Crawler
Ad Click Aggregator
FB Post Search
Yelp
Instagram
Strava
Distributed Cache
Online Auction
Job Scheduler
News Aggregator
Price Tracking Service
Robinhood
Google Docs
Payment System
Metrics Monitoring
Online Chess
ChatGPT
Real-time Updates
Dealing with Contention
Multi-step Processes
Scaling Reads
Scaling Writes
Handling Large Blobs
Managing Long Running Tasks
Redis
Elasticsearch
Kafka
API Gateway
Cassandra
DynamoDB
PostgreSQL
Flink
ZooKeeper
Proximity Search
Time Series Databases
Data Structures for Big Data
Vector Databases
Vote For New Content
Pricing
Sign in / Sign up
Search
⌘K
Pricing

Tutor

Get Premium
Common Problems

Online Chess

Real-time Updates
Dealing with Contention
ByEvan King·Published ·
hard

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 shared clock, and climb a global rating leaderboard. The server validates every move and owns both clocks, so neither player can cheat the rules or the time.
A quick primer if you don't play much. Two players alternate moves on a shared board, and each side has its own countdown clock set by the time control. Games run anywhere from classical at hours a side down to a minute a side in blitz and bullet, where players have only seconds per move and every bit of delay eats into their clock. Players also carry a skill rating that drives who they get matched against and where they land on the leaderboard. We'll build a single game first, then use the deep dives for the parts that get hard at scale, matchmaking, running a large fleet of game servers, and keeping the clock fair across players with different network latency.

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
  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, both updating shortly after games finish.
Below the line (out of scope)
  1. Spectating live games and broadcasting popular boards.
  2. In-game chat, friends, and social features.
  3. Puzzles, training, and post-game analysis or replay.
  4. Tournaments and arena play.
  5. 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 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 match players fairly at scale?

Do we need to shard the pool across Redis nodes?

What happens if that Redis node goes down?

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?

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
Buy Premium

Currently up to 20% off

Hello Interview Premium

System Design Guided Practice
Exclusive content
Recent interview questions
Learn More
Reading Progress

On This Page

Understanding the Problem

Functional Requirements

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 match players fairly at scale?

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?

Some additional deep dives you might consider

What is Expected at Each Level?

Mid-level

Senior

Staff+

Questions
Meta SWE Interview QuestionsAmazon SWE Interview QuestionsGoogle SWE Interview QuestionsOpenAI SWE Interview QuestionsAnthropic SWE Interview QuestionsEngineering Manager (EM) Interview Questions
Learn
Learn System DesignLearn DSALearn BehavioralLearn ML System DesignLearn Low Level DesignGuided Practice
Links
FAQPricingGift PremiumHello Interview Premium
Legal
Terms and ConditionsPrivacy PolicySecurity
Contact
About UsProduct Support

7511 Greenwood Ave North Unit #4238 Seattle WA 98103


© 2026 Optick Labs Inc. All rights reserved.