DEV Community

Discussion on: System Architecture for Edaqa's Room

Collapse
 
nestedsoftware profile image
Nested Software • Edited

My understanding is that the message service finds old/stale data in the live database and uses redis to move this over to the long-term storage database - i.e. if a game is being actively played, the data is not moved. If a user returns after a period of time to continue a game, is the idea that the game server issues a message on the redis queue to retrieve the data from the long-term storage database back into the live database?

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

Messages are live games are moved to the long-term storage as well, clearing out the Redis store on each sweep. When a user connects to the game it will load both the messages from the long-term storage as well as the live database.

The engine is event source based, so no "current" state is ever stored. This will need to be changed long-term if I wish to support longer games.

That said, there is a minimal state in the Redis DB that needs to be restored if the game has been completely purged (which happens infrequently). This is no more than the count of messages and total count of players.

Collapse
 
nestedsoftware profile image
Nested Software

Does that mean the game server collects/replays the existing messages when resuming a game to send the appropriate initial state to the client?

Thread Thread
 
mortoray profile image
edA‑qa mort‑ora‑y

Yes. The client starts a "reset" state for the game and replays all the messages to get back to where it was.

Even for a 6-7 players over an hour or two this only adds up to 6-7k messages.