Design Online Chess: Real-Time Moves, Fair Clocks and Matchmaking

A player chooses a time control such as 5+3 blitz and asks for a game; the system finds an opponent with a comparable rating. Once paired, each move a player makes should appear on the other board immediately. Both sides have clocks, with an optional increment added after each move, and running out of time loses the game.

When the game ends, both ratings are recalculated with a system like Elo or Glicko, and the complete move list is saved for later review. Spectating, tournaments and anti-cheat analysis are excluded. Each is valuable, but they build on top of the core loop of matching, playing and recording, which is where the interview focus belongs.

The latency target is under 100 ms for a move to reach the opponent, because in bullet games a tenth of a second is a meaningful slice of the clock. Fairness is equally strict: only the server decides whether a move is legal and how much time remains, since a tampered client could otherwise lie about either.

Games must survive disruption. A player's network dropping or one of our machines failing should never lose the position or the clocks. Matchmaking should feel snappy too, with most players seated in a game within a few seconds. Notice that throughput is not on this list; the constraints are about responsiveness and trust.

Assume 10 million games per day, which is about 116 new games every second. At around 80 moves per game, the system handles roughly 9,000 moves per second on average and perhaps 30,000 at peak. If a typical game lasts ten minutes, about 70,000 games are in progress at any moment, which means around 140,000 open player connections.

Storage is tiny by comparison. A completed game with metadata and the move list is roughly 1 KB, so 10 million games produce about 10 GB a day and around 3.6 TB a year. The takeaway is that this is not a big-data problem. The challenge is managing many long-lived connections and routing small messages with very low latency.

Four entities model the domain: Player, Match request representing someone waiting in the queue, Game, and Move. Keeping the match request separate from the game makes it easy to cancel a search without touching game records.

POST /matchmaking with a time_control returns a ticket_id while the server searches. During play, both clients hold a WebSocket on /games/{game_id}; the client sends moves like e2e4 with a move number, and the server pushes moves, clock values and the final result. After the game, GET /games/{game_id} returns the full move list, result and rating changes. WebSockets are the natural fit because both sides need to push messages at unpredictable moments.

Clients connect through a WebSocket gateway whose sole job is maintaining one persistent connection per player and forwarding messages. When someone requests a game, the matchmaking service places them in a waiting pool stored in Redis, organised by time control and ordered by rating. Once it finds a suitable pair, it creates the game on a specific game server.

From that point, every move for that game is routed to the same game server. It validates each move, runs the clocks, and after every move writes the current board and clock state to Redis, so the authoritative state never lives only in one process's memory.

Each game event is also published to Kafka. One consumer persists completed games to the game database for history and analysis, while another, the rating service, reads results and adjusts both players' ratings. This keeps slow work like rating calculations off the latency-critical move path.

The simplest strategy pairs the next two people in line regardless of rating. Matches are instant, but a newcomer might face a master, which is miserable for both. The opposite extreme, requiring nearly identical ratings, produces balanced games but leaves players at unusual ratings waiting indefinitely, especially during quiet hours.

A widening rating band balances the two. The search starts narrow, say within 50 points, and expands every few seconds the player keeps waiting. Busy periods produce tight matches quickly, while quiet periods still find someone eventually. In Redis, each time control gets a sorted set whose score is rating, so finding candidates inside a band is a single range query.

The hazard is concurrency: two matchmaker instances could each select the same waiting player. Removing both players inside one atomic Lua script prevents that; if either has already been taken, the script fails and the matcher simply searches again. Because pools are split by time control and region, they shard cleanly across Redis nodes.

Every move carries a sequence number alongside the notation, which lets the server discard duplicates caused by retries and reject moves that arrive out of order. On receipt, the game server checks that it is this player's turn and that the move is legal in the current position. The client's own validation is only for user experience; the server never trusts it.

Clock accounting also happens on the server, using its own timestamps. It subtracts the time elapsed since the previous move from the mover's clock and then adds the increment. A small lag compensation allowance prevents players on slower connections from being penalised for network delay they cannot control.

After updating, the server writes the board and both clocks to Redis and pushes the new position and remaining times to both players. One subtle point: a player who never moves again must still lose on time. So the server schedules a timer for each game that fires at the exact moment the active clock would reach zero, ending the game without waiting for input.

Each game is owned by exactly one server, chosen by consistent hashing on the game ID. Both players' connections and all moves for that game converge on the owner, which avoids coordinating state between machines on every move.

Dropped connections are routine on mobile. When a client returns, it sends the game ID and the last move number it saw, and the server replies with only the missing moves and current clocks. Meanwhile the absent player's clock continues to run, and if they stay away beyond a configured limit, the game is scored as abandoned.

If a game server dies, the hash ring assigns its games to another server, which reads the most recent position and clock values out of Redis while both clients re-establish their sockets and carry on. Kafka holds every move as a durable log, so even if Redis loses data, the full game can be reconstructed and saved. The result is that no single failure erases a game in progress.

Widening the rating band faster shortens queues but produces more lopsided pairings; the expansion rate is a tunable dial. WebSockets deliver instant updates in both directions, but stateful connections complicate deploys and load balancing compared with stateless polling.

Making the server authoritative guarantees fair play at the cost of extra CPU for validating every move and running every clock. Splitting live state in Redis from history in a database keeps the hot path fast, though it introduces a sync step that must be reliable. The guiding principles are that the server referees, game state lives outside any single process, and moves are logged durably.