I agree it’s a good idea to store the history in such a context (in fact it’s probably a requirement), but I don’t see how it’s safer to materialize the balances at query time. If your database is functioning properly then you should be able to transactionally update the history and balance without issues. If your database is corrupting your data then you’re cooked regardless, it could just as easily corrupt the history!
Materializing the state from the events on every single query would be prohibitively expensive for practically any production use case, I would think. Banks in particular run huge numbers of transactions through clearing accounts IIRC, there is just no way you could actually do this in practice.
Tigerbeetle for example (which is specifically designed to do this one exact thing) stores transfer history by default, but I’m fairly sure they also keep track of the balance for all accounts at the same time. They ensure the data is not corrupted by being really careful about properly checksumming everything all the time, which if you read their design documentation you will realize is actually incredibly difficult (ssd manufacturers and kernel developers hate us).
But again, if your database is not providing correctness guarantees there is no winning anyway!
Yeah, that makes sense to me, but my understanding is that’s just an audit log, and that event sourcing is doing “something else” (where I don’t understand what “something else” is).
) don’t care about this difference, then event sourcing will probably not add a lot of value and not be the best choice.