System Requirements

Functional :

1. User Sign-up and Authentication
   1. Allows users to securely create accounts with unique credentials
   2. Implements authentication mechanisms such as email verification or OAuth for user identity verification
2. Game Matching
   1. Pairs users for matches based on their ELO rating or randomly for first time players
   2. Ensure fair and balanced match-ups to provide an enjoyable gaming experience for players of all skill levels
3. Real Time Move Updates
   1. Provide real time updates to players when their opponent makes a move
   2. Update the game board interface and match history accordingly to reflect the latest move
4. Move Validation According to Chess Rules
   1. Implement a method to validate moves according to the rules of the game
   2. Ensure that players cannot make illegal moves during a game
5. Game Room / Session Management
   1. Create and manage game rooms or sessions for each chess match
   2. Allow players to join, leave or spectate ongoing chess matches
6. Game Completion and Result Recording
   1. Determine game outcomes based on chess rules
   2. Record game results and update players statistics accordingly and update their current ELO rating according to an ELO calculation algorithm

Non-Functional:

1. Scalability
   1. The system should be able to scale to handle millions of users and thousands of concurrent games
   2. Ensure that the architecture is horizontally scalable to accommodate increasing load and user growth
2. Real Time Performance
   1. Real time move updates should be delivered with low latency to provide a responsive gaming experience
   2. Minimize network latency and optimize server side processing to ensure smooth gameplay
3. Security
   1. Implement robust security measures to protect user accounts and game data
   2. Use encryption for data transmission and storage, and implement proper authentication and authorization mechanisms to prevent unauthorized access
4. Reliability & Availability
   1. Ensure high availability of the service to handle peak traffic periods and minimize downtime
   2. Implement redundancy and fail-over mechanisms to mitigate the impact of server failures and ensure continuous service availability
5. Data Integrity
   1. Maintain data integrity by ensuring that game states and player statistics are accurately recorded and updated
   2. Implement data validation and error handling mechanisms to prevent data corruption or loss
6. Performance Optimization
   1. Optimize server side processing and database queries to minimize response times and maximize throughput
   2. Use caching mechanisms to reduce database load and improve overall system performance
7. Cross Platform Compatibility
   1. Ensure that the system is compatible with a wide range of devices and platforms, including desktops, laptops, tablets and mobile phones
   2. Ensure a responsive and user friendly interface that works seamlessly across different screen sizes and resolutions

Capacity Estimation

1. We assume a total of 10 million users, 1 million daily active users, 2 million games played per day and an average 50 moves played per game counting both players
2. 2 million games played per day, 50 moves made per game on average, leads to 100 million moves made. This is the number of API calls made to our service in a day just for games alone
3. We have 10 million total users, let us assume that each user needs 1 MB data for their profile to be stores, which would include their profile picture, personal information like their username, first and last name, location, email, password etc. All this data will be encrypted. Thus, we need 10^6 * 10^6 bytes of data = 10^12 = 1 TB of user data
4. For the games moves, let us assume that each move makes us store 1 KB data. In a day, we record 100 million moves, meaning 10^11 bytes of data or 100 GB data generated each day
5. In a month, we would record 30 * 100 GB = 3 TB data
6. In a year, we would need 36 TB data
7. In 10 years, we would need 360 TB data. Accounting for redundancy, we can assume that our service will need 1800 TB of data over 10 years
8. Adding in user information and other data needs that we have not outlined here, we can assume that including everything, our service would need 2000 TB of data over 10 years, which is 2 PB data

API Design

1. User Management APIs
   1. Sign-Up - Allows users to create a profile
   2. Login - Allows users to login to their profile
   3. Logout - Allows users to logout from their profile
   4. Profile Information - Allows users to view their profile with data such as games played, results of matches, their current ELO rating etc.
   5. Update Profile - Allows users to update their profile
   6. Reset Password - Allows a user to reset their password
2. Game Operation APIs
   1. Create Game - Allows users to create a new game between them
   2. Join Game - Allows users to join a game
   3. Leave Game - Allows users to leave an ongoing game
   4. Spectate Game - Allows users to watch a game
   5. Forfeit Game - Allows users to resign from a game
3. Move Validation APIs
   1. Validate Move - Validates move made by a user according to chess rules
   2. Undo Move - Allows users to undo their last move (usually not supported)
4. Real Time Updates
   1. Subscribe to Game Updates - Subscribe a player to real times updates of a game
   2. Unsubscribe to Game Updates - Unsubscribe a player to real time updates to a game
5. Game Stats APIs
   1. Get Game Stats - Retrieves the stats of the current game, including the position of the pieces on the board and move history
   2. Get Game History - Gets the entire move history of the game
6. Leader-board APIs
   1. Get Leaderboard - Gets the current ranking of players across the whole player base
7. Misc APIs
   1. Search User - Allows a user to view the profile of another user, if present

Database Design

1. We use a relational database to store user and game data since all of our data has relational dependencies. Relational databases support ACID transactions, complex queries, provide strong consistency and are thus suitable for managing user data, game data and move history
2. We partition data to improve performance, scalability and manageability.
3. We partition user data based on userID. Each partition can contain users with IDs in a specific range. This ensures that data is evenly distributed across partitions and allows for efficient retrieval of user information
4. We partition game data on the basis of game ID or game start time. Either of those choices will mean data is evenly distributed. Partitioning by game start time will help immensely in managing historical game data effectively
5. We can partition move data on the basis of game ID. All data for a specific game will be localized and easily retrievable for each game
6. No geographic partitioning is needed for move unless there are specific requirements for data localization or regulatory compliance
7. All of our databases will be horizontally scaled
8. We will employ sharding using the partitioning strategy given above and replication to ensure data redundancy
9. Database replicas can help in case of read operations

High-Level Design

graph TD; subgraph "Frontend Application" A[User Interface] --> B[Game Interface] C[Move Input] --> B end subgraph "Backend Server" D[Game Logic] --> E[Matchmaking] F[User Management] --> E E --> G[Database Communication] end subgraph "Real-time Communication Service" H[WebSocket Server] --> I[Move Updates] H --> J[Chat Functionality] end subgraph "Database" K[User Data] --> L[Game Data] L --> M[Real-time Updates] end N[Game Engine] --> L N --> O[AI Opponent]

1. Front-end Application
   1. User Interface: Provides a user-friendly interface for players to interact with the chess game
   2. Game Interface: Displays the chess board, pieces, and game status.
   3. Move Input: Allows players to input moves using drag-and-drop or click interactions
2. Back-end Server
   1. Game Logic: Manages game rules, move validation, and game state transitions
   2. Matchmaking: Matches players based on skill level or randomly for games
   3. User Management: Handles user authentication, registration, and profile management
   4. Database Communication: Interacts with the database to retrieve user data, game states, and move history
3. Real-time Communication Service
   1. WebSocket Server: Facilitates real-time communication between clients (web browsers) and the backend server.
   2. Move Updates: Sends move updates to players in real-time to synchronize game states
   3. Chat Functionality: Enables players to communicate with each other during games
4. Database
   1. User Data: Stores user profiles, authentication details, and preferences
   2. Game Data: Stores game states, move history, and match outcomes.
   3. Real-time Updates: Stores temporary data for real-time communication, such as websocket connections
5. Game Engine
   1. Chess Engine: Implements the rules of chess, move generation, and move validation.
   2. AI Opponent (Optional): Provides computer-controlled opponents for single-player games.

Request flows

Detailed component design

1. WebSocket Communication:
   1. Utilize websocket technology to establish persistent, bidirectional communication channels between the server and clients.
   2. websocket connections enable real-time data transmission, allowing clients to receive immediate updates from the server without the need for frequent polling.
2. Server as Single Source of Truth:
   1. Designate the server as the single source of truth for game state and player actions.
   2. All client interactions, including move submissions, chat messages, and game events, should be relayed to the server for validation and dissemination to other clients.
3. Broadcasting Updates:
   1. Implement broadcasting mechanisms on the server to distribute updates to all relevant clients in real-time.
   2. When a player makes a move or sends a chat message, the server broadcasts these updates to all other players in the same game room, ensuring that everyone stays synchronized.
4. Timestamps and Sequencing:
   1. Include timestamps or sequence numbers in messages sent between the server and clients to maintain the order of events and resolve any potential inconsistencies.
   2. Clients can use timestamps or sequence numbers to reconcile updates received from the server and ensure that they are processed in the correct order.

Trade offs/Tech choices

Failure scenarios/bottlenecks

Future improvements