System requirements

Functional:

• You can sign up as a player
• You can keep track of the number of wins and losses
• You can pair with players to play a chess match based on your win/loss count
• After every match the win and loss count is updated for each player

Non-Functional:

• Reasonable latency (0.5-1 second)
• Real time update
• Handle multiple games at once

Capacity estimation

Traffic Estimations

• 10 million users
• 5 million games played a day

Storage Estimations

• assuming we keep the username(50 bytes), email(50 bytes) wins(4 bytes) loss (4 bytes)
• Total storage is (104 bytes * 10 million) = 1000 MB

Bandwidth estimations

• 5 million games a day -> 58 games a second -> 58 KB a second

API design

sign_up(username, email) -> saves user information into database

find_match(username) -> finds a match for the user

move(username, piece, startX, startY, destX, destY) -> moves a piece from (startX, startY) to (destX, destY). The system will verify whether the move is legal

Database design

When keeping the information of users, it is relatively simple, we can simply use SQL database or we can also use a NoSQL DB like MongoDB for scalability

High-level design

Client will connect the backend server which connects to the database

Request flows

User can sign up which adds a record into our users database

User can request to match with another player to play a chess match, the server will then find a match for you to play

after each match, the win and loss count for each player is updated

Detailed component design

The main question is how can we ensure that the system is able to handle multiple simultaneous games at once and for our service to be able to provide a seamless and responsive gaming experience.

The answer is through sockets. When you first send a find_match request, you establish a persistent socket with the server, this persistent socket allows data to be transferred quickly without the need to reestablish a connection, it also allows the server to send data over to the client as the server will know the IP and port number of a particular client. First we must have a queue of (username, socket) pairs where for each queue, there is a range, from 0-5, 10-20, 20 -50, 50 - 100, 100+ wins. Meaning if you have 15 wins, you will be searching the 10-20 queue. if there is no one in the queue, you will be added to the queue of the server. Else if there is a person, then you will be matched with the person. The (username, socket) pairs of both users will then be retrieved to play a game.

Before a game starts, the server creates a chess board using a 2D array. This 2D array should not be more than 512 Bytes for each match hence it is relatively space efficient. When a user makes a move, the system will first determine if the move is a valid move, once moved, the system will also check if a checkmate is made. If so, the match ends and the win and loss count for the respective users are updated

Trade offs/Tech choices

All matches are conducted in a server, a server can serve multiple connections at once and it provides fast responses for each move made. However, that being said, it is not very scalable. In order to make the system scalable we will have to buy more servers, which is expensive

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

Allow users to view other people's matches, this requires a new socket, and the board of the 2 players