# With this MMOG architecture, how can I avoid losing games when the server goes down?

I am fairly new to game designing and am trying to design game engine architecture for MMOG poker game. My major problem is scalability. Old Legacy code written in python runs everything on single process. Clients and server talks using xml based protocols. Following is old architecture.

admin -> DB (mysql) <-> backend <-> game-engine + login-server <-> client


I came across old reddit post and particular comment. What I feel, I need similar kind of architecture. So I am planning to implement following architecture along with admin and db.

1. backend cluster ( to interact with db)
2. Player Server cluster (handles player authentication and events from clients)
3. gamelogic server cluster (executes game logic)
4. redis-cluster (for caching states of ongoing tables)
5. directory-service + routing server(all clusters will talk with it and all communication will be done through it. initially planning to go with single such server and later make it distributed. Something like this. please see section 'Distributed Directory Service' and 'Distributed broker')

I need to build it using Twisted because of client constrains and legacy codebase.

In this architecture I am confused at one point particularly. Suppose I have multiple tables on one game-logic server and it goes down. How can I address this situation without losing game?

• This seems really obvious to me: The gameserver reboots, gets the last saved state from the DB, continues its simulation at that point and starts to accept player connections again. But this seems so straightforward and obvious that I seem to miss some complication in your question. Can you point me to where the problem is with this? – Philipp Dec 6 '17 at 13:21
• Hi Philipp, thnks for comment. Ideally when one gameserver reboots, game should continue from another gameserver. To make it work, either all operations can be performed over redis ( But redis can be single point of failure ) or may be, keep writing states in redis and when one node goes down, some monitoring/provisioning node should instruct another node to load game. I was looking for different strategies ( or standard partterns ) and their trade offs. – userx Dec 7 '17 at 19:41
• There were some more questions in original one, mostly regarded with engine-architecture. But it was updated to single question by Alexandre recently. That is fine though. – userx Dec 7 '17 at 19:44