"We can't do Event Sourcing. We're not starting from scratch." This is one of the most common objections I hear when consulting teams on Event Sourcing. And it's understandable. Most teams don't have the luxury of a greenfield project. They have existing systems, legacy code, and ongoing business requirements. The idea of introducing Event Sourcing into that reality feels impossible.
A few years ago, a bank where we had one of our business accounts lost a transfer of 35,000 Euros. The money left one account but never arrived at the other. It happened between Christmas and New Year, so at first we assumed it was just slow. It was not slow. It was gone.
We complained. We got the money back. We changed banks. So far, so good.
But here is the thing: 35,000 Euros is noticeable. Someone checks the account, sees a missing chunk, raises the alarm. But what if it had been 3 Euros? Or 3 cents? Would anyone have noticed?
When developers first encounter Event Sourcing, they bring their mental models with them. Years of working with objects and tables have shaped how they think about data. And so, when they hear the word "Aggregate," something familiar clicks in their brain: an Aggregate must be like an object, and objects map to tables. This intuition feels right. It's also wrong, and it leads to Event Sourcing that looks suspiciously like CRUD with extra steps.
A plane touches down at a busy airport. In 45 minutes, it will take off again. Between landing and departure lies a precisely orchestrated ballet: refueling, catering, cleaning, technical checks, crew handover, baggage handling, and passenger boarding. All of this happens in parallel, all under time pressure. And all of it is documented. Not as an afterthought, but as the core of the operation. We work with an airport where exactly this challenge exists: ensuring that every action during a turnaround is recorded, traceable, and tamper-proof.
When I consult customers on Event Sourcing, there's a moment that happens almost every time. The team looks confident, maybe even a little proud. They tell me: "Actually, we already do Event Sourcing." And then they show me their events. UserCreated. OrderUpdated. InvoiceDeleted. My heart sinks a little.
This is not Event Sourcing. This is CRUD with event syntax. It has the shape of events but none of the semantics. And that distinction, subtle as it may seem, is the difference between a system that speaks the language of your business and one that speaks the language of databases.
First of all: We wish you a happy new year! We hope you had a wonderful Christmas and an amazing time! 🎉
Speaking of time, let's talk about one of the most commonly misunderstood concepts in event sourcing: when did something actually happen?
If you've worked with events for a while, you've probably noticed that every event comes with a timestamp. In CloudEvents, this is the time field, which EventSourcingDB sets automatically when an event is stored. It's tempting to use this timestamp for business logic. After all, it's right there, readily available. But doing so can lead to subtle bugs and incorrect assumptions. Here's why, and what to do instead.
On May 5th, 2025, we shipped EventSourcingDB 1.0. After years of building, learning, and refining, we finally had a product we were proud to put in front of the world. That moment marked the beginning of something we had dreamed about for a long time. Now, as the year draws to a close, it's time to look back at what has happened since then – and to say thank you.
Golo: Bastian, you are working as a freelancing software developer with a focus on Domain-Driven Design (DDD), Event Sourcing, and related topics. And you've been advocating for Dynamic Consistency Boundaries (DCB) for a while now. Can you tell us a bit about your background and how you got into this space?
"Should we use one EventSourcingDB for all our services, or should each service have its own?" This question comes up in almost every conversation about service-based architectures. Teams want to keep things simple. One database sounds easier to manage than five. The appeal is understandable.
But here's the thing: this isn't a question specific to EventSourcingDB. It's one of the most debated topics in software architecture, regardless of database technology. Whether you're using PostgreSQL, MongoDB, or an event store, the fundamental question remains the same: should multiple services share a database, or should each service have its own?
If you've read Tolkien, you know that "One Ring to Rule Them All" didn't end well. The same is true for shared databases. What looks like elegant simplicity becomes a source of coupling, conflict, and constraint. Let's explore why.
Imagine a city library that has been collecting catalog cards for over a hundred years. In 1920, librarians recorded "Author" and "Title." In 1970, they added the ISBN. In 1990, "Author" became "Authors" (plural, to accommodate co-authors). In 2020, they introduced e-book formats and licensing information.
Here's the thing: the old cards are still there. You can't "update" a card from 1920. And yet, the modern library system must understand all of them, from the handwritten notes of a century ago to yesterday's digital acquisition.
Event sourcing faces the same challenge. Events are immutable facts. Once written, they stay forever. But requirements change, domains evolve, and mistakes get discovered. How do you version something that can't be changed?