A machine fails. You know it failed. But do you know why? Traditional systems store only the current state: Temperature 72°C, RPM 1,200, last service three months ago. You see the end state, but not the journey. You see where the machine is now, but not how it got there. We work with a customer who builds digital twins for industrial machines, and they faced exactly this challenge.
"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.
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?
Want to try EventSourcingDB right now? Here's all you need:
docker run -it -p 3000:3000 \
thenativeweb/eventsourcingdb run \
--api-token=secret \
--data-directory-temporary \
--http-enabled \
--https-enabled=false \
--with-ui
Done! EventSourcingDB is running at http://localhost:3000.