It’s time for bi-temporal event sourcing in part eight of my event sourcing series. In this post, I’ll stick to the basics – at least I hope so. 😅 Bi-temporal event sourcing means that we have two timestamps associated with an event: The first timestamp tells us when the event entered the system, or when the system acquired the knowledge. We call this the application timestamp. The second timestamp states when the event takes effect – the effective timestamp. This is...
During my series on event sourcing, I got a question a couple of times: “Why don’t you use an event sourcing library? Why have you built your own kind of library?” So part seven is about the trade-offs of using out-of-the-box libraries versus building your own – even today.
Event‑sourced systems must evolve, and sooner or later, events need to change. In the sixth part of my series on event sourcing, we are looking at versioning of events (schemas) and whether migrating or keeping all old versions is the way to go. Of course, there are trade-offs involved regarding long-term maintainability and overall simplicity.
In the fifth part of this event sourcing series, I’ll show you how we use compensation of events to handle failed commands and events that should never have happened. Sometimes, things go wrong – a command fails because the database is overloaded, there is a bug in the code for some edge case, the system is out of memory, the infrastructure misbehaves, etc. Or a user did something that should never have happened, like importing the wrong data set. When this happens, we want the...
In the fourth part of my event sourcing series, we’ll take a look at why long event streams – streams with lots of events – are a problem and what options there are to deal with this problem. Why read models are not always enough to solve performance issues due to long event streams. And of course, I’ll discuss the involved trade-offs.
This is part three of my event sourcing series. In the first two posts, I showed you approaches that rely solely on projections. Now is the time to introduce read models to support all your query needs. And maybe, solve some performance issues as well. Of course, I’ll discuss the downsides of read models, too.
To finish this post, I’ll do a deep dive into a code example.
This is the second post in my series on event sourcing. Last time, we saw a simple implementation based only on projections. While simple, it can only be queried by the event stream ID. In this post, we look at an approach that allows for more lookup criteria while still avoiding a read model.
This is the first post in a series about event sourcing. I’ll start with a very simple event sourcing implementation that is often good enough. Most of our event streams are implemented in this simple approach. In the following posts, the concepts will be extended to match additional requirements. I’ll touch on read models, consistency, long event streams, archiving, compensation, event skipping, lifetimes, and bi-temporal event sourcing. Every post will explain the concepts and our...
We started using event sourcing over ten years ago. One of the hardest lessons was that there is a kind of events that is not obvious at first but have a big impact on your system design. I call this kind secondary domain events.
In this post, I’ll explain what secondary domain events are, and how they impact the design.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In the final part, we examine how LLMs affect testing and conclude the series.