We are going to built a chess.com clone to get some practice around webSockets.

You can read this article to learn about -
Websockets

Our App will have these features

• User can play with other users in realtime.
• All the Data is stored in the DB
• If one user left the game accidently. He/She can again join the game using the gameId.
• Have User Authentication
• Have Proper Game Logic
• User can see all the Moves

Schema Design

we will be having 3 tables - Games, Moves, Users.
Games table will store the individual games each game having their own unique ID [primary key] , playerIDs[foreign key], startTime, Result & one to many relationship to the Moves table.

Moves table will have GameId [ foreign Key ] , to , from , playedAt.

User table will have id(Primary key),name,email(unique),gameAsWhite : Game, gameAsBlack : Game[]

System design

Your server has to be stateless. But in this case we are using in-memory object Game[]. Why?
Due to latency issues. That's why we also storing in Server also.

It also has recovery mechanism in case a server dies then we can get the data from the DB.
When user make a move it got updated on the server side then sent to other node and after that stored in DB.

In case DB is down, we push that in a in-memory array, failedDBMoves and try to add that after some time.

Scaling

1.By Sharding
What we can do is we can increase the number of server to scale our application, but we have to make sure the players which are playing to each other are connected to the same server.

Problem -1
But isn't it will be best if user can connect to their nearby server.
Problem -2
Let's suppose a server can handle only a 1000 ws connections , what if our game has more than 1000 spectators then what we will do.

1. Using Pub-Sub if there are many people then using a pubsub will make more sense. User Makes the move and it got published and reached to the server that has subscribed for that. Also user can connect from any available server.