This assumes the content in the commit log are client events, not CRUD on table data actions (events are higher order).
> the whole event history is not useful and consumes huge amounts of space
When a greenfield project is starting up, data is gold. 8TB drives are $242. Create a data lake from the start.
And data is the new oil is definitely a businessweek cargo cult. None of the event data was of any use on the projects I worked on. We were under mandate to find something to do with it and still couldn't. The closest useful thing was allowing undo and replaying past events but we already had that on Postgres with hibernate auditing on interesting tables (money related stuff)
Quite, which is why I'm both writing a book, and developing tooling to help with this problem. ES/CQRS is a nice pattern that you can explain to someone on the back of an envelope in 5 minutes, but the devil really is in the details.
I'm hopeful that one day it will be a common and useful pattern but it desperately needs language integration to help with the details. That's why right now I can just say stay the hell away. Looking forward to advances in the space to make it viable in production
Invaluable when handing a time series of financial events subject to adjustments and corrections. For instance, backdate interest adjustments due to misbooked payments, recalculate a derivatives trade if reported market data was initially incorrect, calculate adjustments to your business end of month P&L after correcting errors from two months ago.
After working on several such systems, I strongly believe you should keep data storage concerns in the database. Moving it to code implementation is a massive amount of overhead for no benefit.
I worked on multiple Event Sourcing CQRS based systems and I see no advantages vs traditional databases.
The event stream is exactly the same as a commit log in a regular DB. Building "projections" is the same as making views or calculated columns. In my experience storing the whole event history is not useful and consumes huge amounts of space. Just like everyone compacts their commit logs, you don't have to, and if you don't, isn't ES the same thing with extra steps? It stores all the changes to tables and views, which are exactly the same as projections. With ES + CQRS combined you're basically replicating a database, badly.
Sorry to be so negative about this topic but I've worked on several of these projects at a decent scale and it's been the biggest disaster of my professional life. The idea may be viable but tooling is so bad that you're almost surely making a huge mistake implementing these patterns in production code.