We already have a replayable log (that's the point of the MySQL log after all), but we couldn't rewind the entire system. Consider, for instance, a new user that created an account and deposited funds. If we roll the system state back we would have to manually allocate all of those and manually recreate the users. And, too, consider the exact issue we've got above, where a user divested and withdrew - how do you roll that back? You can't, so you have to move forward with the system in the current state.
::sigh::
That's just rolling back the database, and not what I meant at all. A replayable log is logging all the individual events (e.g. bets, investments and divestments), in such a way that if you found a mistake had occurred (or in this case, fraud) you could fix the mistake (in this case, delete the bets) then replay everything so the investors balance is exactly is if the fraud never occurred in the first place.
It's actually just a good practice to be in, when ever I mutate state I *always* store the cause of it. (e.g. if someone transfers money, I log an event of the transfer. If someone claims the faucet, I store the details of that, if someone invests I store a record of it (and things like how much the bankroll was before they invested) etc).
And probably the other mistake people make, is over-constraining their database to not allow negative values. e.g. While a user balance never should be negative, the system should support it as cases like this might cause some accounts to legitimately be negative (them withdrawing gains they shouldn't have) or even deposits reverting after a blockchain reorg etc.
It's great for a disaster recovery situation like this, and it's great from an audibility perspective. It's probably too late for this time around, but it might be worth designing around in the future.