First Approach: Store the state in database and play with database queries. Could a database handle the load, as poker is quite fast paced, and I have to query/update database for each player move.

Second Approach: Store the state in memory. What kind of architecture/implementation is needed to achieve this?

What are the pros/cons of each approach, what other options do I have?

What is the best fit for poker, and/or chess?

  • \$\begingroup\$ What language are you using for your server-sided programming? Not decided yet? Then this is a "which technology to use" question, which is off-topic. \$\endgroup\$
    – Philipp
    Sep 10, 2014 at 10:43
  • \$\begingroup\$ @Philipp I use javascript, but the question is language agnostic, though I would wonder what language would be best fit. \$\endgroup\$ Sep 10, 2014 at 10:44
  • \$\begingroup\$ So it is a "what technology to use" question? What a pity. I nominated it for closing then. \$\endgroup\$
    – Philipp
    Sep 10, 2014 at 10:53
  • \$\begingroup\$ wtf Phillip it's not a technology question, it's a side question that which frameworks are available. Main question is is it better to use database or memory to store the gamestate. Not which technology to use! @Philipp \$\endgroup\$ Sep 10, 2014 at 10:55
  • \$\begingroup\$ OK, I edited your question to remove the off-topic parts. \$\endgroup\$
    – Philipp
    Sep 10, 2014 at 10:57

1 Answer 1


From a performance standpoint, having data in memory is orders of magnitudes faster than having it in a database. There are two reasons to put data into a database instead of storing it in memory:

  1. You have more data than fits into memory
  2. You want to make sure no data is lost in case of a (intentional or unintentional) server shutdown

As you already said, poker can be quite fast. To keep response times low, handling each game in memory would be beneficial. However, you might want to estimate how many games you intend to handle simultaneously and how much data you will have per game. When you realize that this will occupy more RAM than your server(s) will have, persisting the whole game state to the database after each move and retrieving it again when the next player makes their move might be necessary. I didn't do the math (I can't, because I don't know your requirements) but eyeballing it I would find it unlikely that this would be required.

However, I would recommend to persist the current state to the database as soon as a round is over, so the chip balance of each player is persisted and no progress is lost in case of a sudden server crash. Having to rollback the current round which wasn't even decided yet would likely be acceptable for most players, but rolling back a high-stakes game several rounds in could make those who already won a lot quite angry.

  • \$\begingroup\$ can you explain a bit more about the architecture to use for handling game logic in memory. \$\endgroup\$ Sep 10, 2014 at 11:09
  • \$\begingroup\$ @user3995789 That depends on which technology you decide to use server-sided (which is a decision we can't make for you). \$\endgroup\$
    – Philipp
    Sep 10, 2014 at 11:11
  • \$\begingroup\$ thanks for the generosity, you can at least mention a few tips, or an example technology, I prefer javascript. should I use/are there existing libraries or is it difficult to implement such a thing. \$\endgroup\$ Sep 10, 2014 at 11:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .