# game server - fault tolerant

If you have for example an MMO with 2000 players, and players are constantly removing / creating / swapping items (and doing some other important things that can't be lost).

If the updates are saved instantly in the database, since they are too many, the database dies. If you save them every "x" minute, there's a window where if your server app dies, players may lose items, and sometimes they may be expensive, let's say 100$, so that can't happen. Is there a design or a guide I could read that handles this issue? The games I play today do not have that problem. • You have 2 things to save: important things and not so important things. You save important things immediately, and you put not so important things in a queue that will be saved 'soon, when there is time'. Other than that, use a server that's able to manage all these transactions, or redesign your game. Apr 24, 2016 at 18:48 ## 1 Answer First, nothing is ever saved instantly in an MMO and there is always a delay specifically to keep the database running smoothly. For casual transactions the common delay seems to be 5-30 seconds, not minutes. Certain events like logging out or transitioning between world spaces will force a fast update. If you watch carefully you'll hear of occasional roll-backs of items when a server area crashes, that delay chosen above is a compromise between optimal server updates and not annoying players too much on the rare crash. Transactions between players should be handled as such, where the end result is only applied once all conditions of the transaction are complete. This is a standard database concept. Second, items which cost real money should be handled the same way as a transfer between players. Wait to tell the player about the item until all conditions of the transaction are complete. Maintain a separate log of these kinds of important transactions, a player won't care if he loses 15 seconds of coins gathered but would care a lot if he lost that$100 item.

In the rare case of a database crash the database itself is backed up regularly (daily) and can be restored. At that point the logs you carefully created above that hold the big item transactions can be applied so at the very least the items show up in the player inventory again.

• Those transactions are what I call "saved instant". If a player gets a new item from another player, the request will be queued and executed asap, and the player will see that transaction asap. I guess I could "delay" a remove item request, but if a person gets a new item from a monster for example, I don't think I can delay that too. Or should I?, I can't know if the item is good or bad at that point (economy changes, so it may be a drop that cost initially 1$, but may cost 50$ later). This is why I said important "things that can't be lost". Obviously I do delay an update of few coins.
– Gam
Apr 24, 2016 at 23:00
• @Phantom If item X (which could have a market value of 50\$) drops from a monster, and the player has not expanded any resource to make it so, it is not important since it's random (best case, if the server crashes, it's going to be a good story to tell). If it's related to a player having spent something (like a special hard cash scroll which increases the chances of drop to 99%), then you must record the drop AND the scroll used at the same time. Apr 25, 2016 at 10:07
• @AlexandreVaillancourt But if the item is stored in a table like the first one in here: gamedev.stackexchange.com/q/120443/81788, it doesn't matter if I delay the query, as I have to make 2 querys anyways for 2 different items. With the second design this wouldn't be a problem of course, but the topic was closed and I don't know what to do.
– Gam
Apr 26, 2016 at 0:22