The concept sounds interesting, but the article doesn't do a great job of explaining how it works. How do I efficiently reconstruct the current state from the event stream? How would the event stream be modelled in the database?
https://www.youtube.com/watch?v=gG6DGmYKk4I
https://www.youtube.com/watch?v=jnDchr5eabI
https://www.youtube.com/watch?v=ArcypYS5XBQ
https://www.youtube.com/watch?v=uODSwR2CIV4
He also maintains samples on GitHub:
https://github.com/oskardudycz/EventSourcing.NetCore
1. Use a database designed for this stuff. Google big query, Amazon redshift, clickhouse..etc. all current data is essentially a type of aggregation. Or in other words it's equivalent to a group-by query on an event database.
It makes sense right? With events I can technically rebuild the current state or the past state of the data through some aggregation query.
2. Rename your relational storage and call it a caching layer that lives next to the event system. It's functionally the same thing but won't trigger any red flags in people who are obsessed with making everything event driven.
The architecture he describes exists. It's just massively complicated so services that utilize it usually do very targeted things. Think Google analytics, data dog, splunk... etc. Etc.
There isn't one 'current state'. That thinking comes from centralising everything in one DB.
You create different states in different systems according to different requirements. If you're building a shopping system, with Purchases and Customers, one service could read events and produce a relational table for finance purposes. Another service could read events and produce a key-value store of customer data. A third service could power an OpenSearch service for searching over products.
> How would the event stream be modelled in the database?
It's a list. If you're using something fit-for-purpose like Kafka, then it's multiple lists (topics, partitions, etc.).