CareerCup

You can long poll but for interview a better answer would be to use sockets such that you create a connection from client to server, and now server can push notification to you when events happens. This in contrast to long polling is less stressful on client as it does not use up as much resource polling.


Its hard to talk about the design here, but I'll give a general overview of how one might go about implementing this at a general level:

- Visual Layer: 
  - GameModel: Current GameModel fetched from api (just some json data model)
  - GameRender: Given a gameModel will render the chess game
  - Create connection with api
     - onUpdate: update current gameModel and re-render game

- Api Layer
  - /get/:create
     - Creates a brand new game model and returns the game model

  - /get/gameModel/:gameId
    - Given game id will query database to get the latest gameModel

  - /get/games/:playerId
    - Given player id, will return array of gameId that playerId has created

  - /post/update/
    - Will update the game with the latest game model. Latest game model is stored in the body of the post request

- Persistance Layer
  - Can choose between sql or nosql. For simplicity, lets pick mongodb which allows us to store 
    json models. This data we store can be optimized and will effect how efficient our request per second is in API layer

#General Userflow
1) User creates a opens up app
 - App checks if user has any game played via /get/games/playerId
 - App shows all games played if any

2) User can either create new game, or click on one of the played game which has a gameId
 - If clicking on a played game, we have the game id so call /get/gameModel:gameId
  - get the game model and render it
 - If creating new game, call /get/create, which returns a new gameModel
  - get the game model and render it

3) Once game model is rendered wait for user to make move
  - Store the move in the game model
  - call /post/:gameId with the current gameId and its gameModel in body of the request

4) Backend accepts the /post/update request
  - Updates database with the new gameModel for the given gameId  
  - Updates database with { gameId: gameId, lastPlayer: gameMode.playerId }
  - For gameId get all players in the game from Database (we may have {gameId: [array of playerid]} in db)
  - Now we have gameModel.playerId and allPlayerId, with that we can get the next playerId
  - Check socket if next playerId is connected, if so, send update gameModel
  - If not then when next playerId connects, it will be their turn

There are few details I haven't talked about, like what exactly does the gameModel look like?
Here is one way it could look :

GameModel: 
 playerId: String #a unique player id
 gameId: String #a unique game id 
 historyOfMoves: Array #Array of moves which we can use to render the chessGame

There is obviously more to this, but thats a general overview. As for scaling, the default answer is to create multiple clusters of API which is gated by a load balancer. So when client request api endpoint, the load balancer intercepts the request, and delegates to a proper server which handles our restful request. And if we need to scale we can simply increase the number of clusters we have to handle more request.


I hope that was helpful to start.

can somebody give me a link to read about such web based designs

Highscalability.com is a good source.

Http question: use long polling from the client, so he can get notifications
Scalability: I would not necessarily say it's not scalable, there is not enough info given here to judge that. But the storage of pants in fields in classical relational manner is a bit hard to scale and unnecessary. You could just store a object as whole which contains the two set of pans with coordinates or the field as a whole. This can then be easily cached as a whole. That's easier to scale.
The password: it's bad practice to store it with encryption, store the hash and a seed, LS :-)

Highscalability.com is fun to read, then search for Google's Jeff Dean videos on YouTube, which I think is inspiring.

To start the session between two players, there should be a service which has a queue of players who are looking for other partner to play the game. This service will match two players based on their ratings and other parameters. Then it will call another service(say it SessionCreateService) to create the session between these two players and continue with matching other players in the queue.

When SessionCreateService will receive the requests , it will create a session between these two players by sending them response and finally GameService will handle the ongoing game.