"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.