# 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.

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).