In applications, specifically web apps when a user performs an action such as pushing an item into a shopping cart or sending a message on a forum, there is an immediate need to persist the data into a database. Meanwhile, an online game has many actions occurring such as player movement. You can't persist all of those movements.
An online game like an MMO for instance has to treat most interactions as ephemeral aka in store in RAM. One needs to change their mindset on the idea that not everything needs to be persisted to database instead consider where data will be read from (visibility), operated and then persisted and flushed out to everyone else. If you need persistence, you need to identify what exactly you want to persist and a rate independently of what's going on.
In a recovery scenario, a flat state desired so that the world session can be loaded quickly. You only want latest persisted data at that point. Long load times means lost users. Append only logs could be used for write ahead logs for certain data like transactions that occur in the game. One really has to architect multiple recovery solutions to accommodate multiple persistence patterns. You will have to throw out transactions in the case that flat state latest time doesn't match up to the transactions loaded in.
Some applications, typically collaborative SaaS applications, act like games where they start up sessions for users when they open up a file and perform operations which happen in memory then eventually persist then flush out to other users. Consensus is a different but important topic. Ultimately when the session closes the final state is persisted into a database.
There's no way to provide always consistent information at all times when it comes to games. You have to live with it and do your best with custom algorithms to keep some form of consistency between user client, service and persistent stores. Knowing and documenting limits is one of the ways to deal with it.