Loading...
Server side will create a userId for the user
POST /signUp/ -> Partial<User>
{
userName: string,
userPassword: string (hash)
userProfile: {
email: string,
phone: string,
gender: string,
age: int,
... other metadata
}
}
user_id will be retrieved in the jwt token in header, so no need to pass it.
POST /game/ -> Partial
{
}
GET /game/:gameId -> Partial
user_id will be retrieved in the jwt token in header, so no need to pass it.
POST /game/:gameId -> 200
{
move: Move {
from: string,
to: string,
chessType: string
}
}
user_id will be retrieved in the jwt token in header, so no need to pass it.
POST /game/:gameId/validateMove -> 200
{
move: Move {
from: string,
to: string,
chessType: string
}
}
GET /game/:gameId/validateGame -> {status: 200, winner: userId}
We will have a User DB(relational database like postgreSQL):
User table
{
userId, string, PK,
userName, string,
userPassword, string,
other fields...
createdAt, timeStamp,
updatedAt, timeStamp,
}
We will have a Game DB - which will be responsible for most READ and WRITE requests
{
gameId, string, --- partition key
player1, string,
player2, string,
state, string,
moves, Move[]
}
We can also have a OLAP db for Game stats
{
userId,
gameId,
winStatus,
duration,
opponent,
...other metadata
}
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
client -> signUp/login -> userService -> user db
client -> match game / play game -> gameService -> game db
client -> view game stats -> gameService -> game OLAP db
For game service, in order to support 100M DAU.
We can do several improvements:
If we want to view the game stats and other players stats, we need to do the query in the OLAP game db to not affect the performance of main game db which will server for production game traffic.
We choose to use SQL db for user db for better atomicity for signup and login operation.
We choose to use noSQL for game DB for higher throughput and latency and consisteny guarantee.
We choose to have a OLAP Game db so that some expensive query will hurt the performance of main Game db.
If we would like to achieve real-time move updates, we can consider use websocket for two players to communicate.
when two players are matched, a webSocket connection will be established from both users to the game service.
The game service can have a real-time update for both users.
We need to scale the service to handle 100M DAU, so we need LB to route the users to different ws server. This can be based on gameId using consistent hashing.
We need to have a game dispatcher after the LB which will responsible for assign the ws server to the two players. In database side, we can persist the mapping in the db and restore the connection if user logged out in a game and try to resume.