Requirements

Functional Requirements:

• Matchmaking pairs players by skill level based on ELO rating.
• Provide real-time move updates between players via persistent connection (WebSocket).
• Enforce chess rules with server-side move validation, rejecting invalid moves.
• Store completed games and allow users to review past games and replay moves.
• Maintain user accounts with profiles, ELO ratings, win/loss records, and game statistics.

Non-Functional Requirements:

• performance under 200ms for the hot path which will be game play.
• scaleability - 20K concurrent websocket connections
• consistency - some latency is fine because the hot path is more important for real time game use.
• security - users need to log in and authenticate

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

Rest API

POST/v1/pairings

{

"elo_rating"

"user_id"

}

Websocket request

wss://chessingameservice.com/ws/games/{gameid}

functional requirement 3

{

"type": move

"gameid": {gameid}

"playerid": {playerid}

"move"

"from": E1

"to": W2

}

functional requirement 4

restapi

GET/v1/{userid}/replay

{

"gameid":

"result": wins/loses/ties

"duration":

"new_eso_rating"

"moves":

}

GET/v1/users/{userid}/profile

{

"userid":

"bio":

"eso_rating"

"wins"

"loses"

"ties":

"gamesplayed":

}

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

• Edge is Envoy as L7 gateway where TCPTLS is established. Also rate limtiing, Auth - Google authentication → JWT token → Envoy validates JWT. Also the LB is distributing connections to the chess game services in a least connection logic to ensure our in chess game service does not get overwhelmed with Websocket long lived connections. Additional it handles connections to matching. Scaling here is horizontal as needed.

• Chess game service which is part of my critical hot path. I'm going to use EC2s here due to the long lived websocket connections. Based on the requirements i'll play four EC2s here run the in game service AND i'll have some backup EC2's for expansion or failure. These EC2's can be scaled vertically but i've sized them based on peak 20000 websocket connections. if a failure occurs here my active_game_event_store is the source of truth. The user would get a "reconnecting" message and envoy would mark the old EC2 as unhealthy and remove. This request would be "least connection" sent to another healthy EC2 who would take ownership of the game. This EC2 would check with the active game event store for gameid:222 and reconstruct the board and moves based on the event log replay. The game will be resume.

• Next my DB which is a sql relational DB. My DB has four tables to represent the data models required for calls. They all have primary keys, and a few have foriegn keys. One note here the DB is out of the hot path. This a READ heavy DB not a write heavy DB. If I required scaling this database I would do so in the form of replica(s). This would also provide us with HA backups. 1 pimary for writes and a few replica's for reads. If the primary goes down if uses the active_game event store as the its source of truth to for active games.

• our matchmaker service is a simple kubernetes horizontal scaling.