Suggestions
Allard Buijze
CTO & Founder at AxonIQ
Allard Buijze is a technology enthusiast and the CTO and founder of AxonIQ, advocating for knowledge sharing and progress in software development.
Allard emphasizes the importance of passing down knowledge to the next generation of developers to enable growth and learning.
Apart from his dedication to software development and research, Allard also enjoys playing tennis as a way to unwind and stay active.
He holds a Bachelor's Degree in Informatics from De Haagse Hogeschool / The Hague University of Applied Sciences.
With a rich professional background, Allard has served in key roles such as CTO and Founder at AxonIQ, CTO of Trifork Amsterdam at Trifork, Software Architect at Trifork, Senior Software Engineer at Accenture Technology Solutions, and Owner/CTO at Digiscape.
Highlights
Event Sourcing "Friday FUD": Data duplication. The bitter after-taste will never really cease to appear with those words. A reminder of decades of data-centric software development.
Strictly speaking, data duplication is not caused by Event Sourcing itself, but rather by CQRS, an architectural style that it is often combined with. But that's not all that important.
Our fear of data duplication comes from the time when our biggest challenge was data consistency. Different systems held their copy of certain data points. Customer data for example. When the customer's address changes, these different systems all needed to get updated. And of course, they didn't.
The solution: we keep 1 copy of the customer data in 1 (or a few) tables in our database. All systems would connect to that database to be sure to get the latest view of the customer. Perfect. Problem solved.
Let's get some statistics about customers. From that same table, of course. Okay, that destroys performance. Let's build a separate LDAP database. Oh, we need to change the structure of the Customer table. But 10 systems depend on it.
Great. We've painted ourselves in a corner where it becomes increasingly difficult to make changes.
The architectural styles evolved, but the sense we need to avoid data duplication remained.
Time to let it go. Let it go... ❄️
First of all, data is rarely just "duplicated". Different parts of a system will have slightly different needs and therefore slightly different views on the same conceptual "thing". The forces that dictate their requirements are also different. That means they will evolve in different directions, eventually. The less restrictions we have, the better it is.
Instead of fearing data duplication, let's use it to release us from the chains of conflicting requirements. If requirements conflict, then each gets a different copy of the data.
There is one thing we need to get right, to avoid falling into the same trap that led to our era of third normal form: consistency. Once the customer details change, we need to ensure that all copies of the data are (eventually) synchronized accordingly.
Now let that be the one thing that Event Sourcing is really, REALLY, good at. Unlike systems that publish events as side-effects, all changes are guaranteed to be represented by an event. Use those events to trigger an update of each copy.
In CQRS/ES, these copies are called "view models" or "projections". They project the stream of events onto a data structure (e.g. a table). Like a movie projected against a white screen. Each projection knows which events trigger an update of their copy of the data.
If you're concerned about the cost of data storage. In the 90s, 1TB of storage cost today's equivalent of $10,000,000. Today, it's around 10$. The time you waste on making systems work in 3rd normal form is orders of magnitude more expensive.
It's time to let go of our fears and open our eyes to the advantages there to grab.
