# Confusion about flow and architecture for basic multiplayer card game state

As a web developer I'm used to a straightforward flow where all interactions typically correspond to a database read/write and the life-cycle corresponds with a single request.

As a learning exercise I wanted to write a basic multiplayer card game and realized I have a lot of confusion about where to best store active game state.

While I know a card game could easily read/write to a database per action, I was wondering if it is as simple as (in my case, a javascript node server):

1. Create a global state object
2. Create an active game object
3. Push it to an array in the global state
4. Perform actions on this active game in memory, broadcast new state to frontend via websockets
5. When the active game is complete, write the results to a database for persistent storage
6. Remove the active game from the state, thus freeing memory?

My questions:

1. Is this a reasonable solution or is it a bad practice? (global variables, memory management, state loss on process crash/restart etc...)
2. Would it make more sense to set up a redis server for handling temporary state?

This is quite different from a frontend perspective where redux/vuex makes handling state a straightforward task, and from what I've read, it is desirable for the backend to be 'stateless' - it just seems weird to me to read/write to a database for things that don't require long-term persistence.

Edit: I also know firebase could be a very suitable solution, I just prefer to avoid vendor lock-in if possible.

• Coming to this question late, but it sounds to me like you understand the trade-offs you're making with this choice. You can store the state in memory at the risk of loss of progress if the server resets during a game (and all clients in a match must use the same server), or you can log progress to a more persistent store for higher reliability (and scalability) at the cost of increased complexity. Whether that trade-off is worthwhile for the kind of game you're making is a question that you're better-positioned to answer, since you know your game and your intentions for it better than we do. Aug 23 at 10:46

You can mock async calls to your mock-server using setTimeout to pretend a typical response delay of say 50ms. Make sure you do this right from the start, for every such call.
For that purpose, suggest separating your front end classes into /client, /server-mock, and /common (which ultimately will be available on both client and server).