[Haskell-cafe] Looking for architecture/infrastructure advice on coping with thousands of concurrent clients

[Alois Cochard]

Hi Isak,


On 9 July 2014 18:40, Isak Hansen <isak.hansen at gmail.com> wrote:

>
> #2 - I'm new to Haskell and would appreciate thoughts on how to store and
> process game state. Imagine a plain application managing 1000 tables of
> poker, responding to player input (that magically appears) and timer events
> (e.g. folding players that fail to take action). What data structures and
> libraries should I be looking at here? Thoughts on concurrency and how I
> organize program flow?
>

If I had to build an system like this, the main design principle  I would
adopt is to not try to share the state of games among nodes, but instead
redirect players of the same game on the same node (where you basically
have a thread processing the event of the game and updating the state in
memory).
Then I would probably use some form of event sourcing to record game action
which could be use in case of node crash to recreate a game state by
replaying events.

The event source could then be used as well to generate stats/views in near
real-time.


-- 
*A\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140709/96039e64/attachment.html>