Data analysis is more important than ever. Data science and AI have become essential tools for many companies. The tools keep getting better: more powerful models, faster computers, smarter algorithms.
But here's the problem: the underlying data is often garbage. And as always: garbage in, garbage out. The best models, the fastest computers, the smartest algorithms – none of it matters if your data doesn't tell the real story.
Imagine you're placing an order in an online shop. You click the "Submit Order" button. Nothing happens. You wait a few seconds. Still nothing. So you click again. And maybe once more, just to be sure. Finally, a confirmation page appears. You've successfully placed your order – or have you? Did you place one order, or three?
This scenario plays out millions of times every day across the internet, and it reveals one of the most persistent myths in distributed systems: the promise of exactly-once delivery. Message queues advertise it. Streaming platforms claim it. Enterprise architectures depend on it. But here's the uncomfortable truth: exactly-once delivery is impossible in distributed systems. The good news? That's perfectly okay, and there are practical ways to handle it.
Imagine it's January 2026. You run a platform with millions of users. An auditor walks in with a specific request: "Show me proof that you captured a GDPR consent event for user #12847 on March 15th, 2024." You know the event exists – it's sitting in your event store. But here's the problem: you can't just hand over your complete event log. That log contains millions of events with sensitive customer data, financial transactions, business secrets, and personal information from thousands of other users.
Domain-Driven Design (DDD) promises better software through a focus on the business domain and a shared understanding between developers and domain experts. That's the essence, distilled to one sentence. But if you actually apply this principle to DDD itself – asking what the domain is, what matters, what can be discarded – you won't end up with what we call "DDD" today. You'll end up with something much simpler.
So why has DDD, after more than two decades, never escaped its niche? Why do so many developers feel overwhelmed by it, confused by it, or think they're not smart enough for it? The answer is uncomfortable but clear: DDD fails at its own claim.
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.
Imagine you're standing at the counter of your local library. You want to borrow a book – let's say it's "2001: A Space Odyssey". You tell the librarian, they check if the book is available, stamp your card, and hand you the book. Simple, right?
EventSourcingDB 1.2.0 is available for download. Since we shipped 1.1.0, we've spent a lot of time listening – at conferences like KanDDDinsky, in customer calls, through GitHub issues, and in direct conversations with teams running EventSourcingDB in production. This release is our response to what you told us you needed most.
May 5th, 2025. After years of development, countless iterations, and exhaustive testing, we finally released EventSourcingDB 1.0. The CI/CD pipeline was green. All integration tests passed. The documentation was polished. We had tested the database on different ports, different operating systems, different deployment scenarios. Everything worked exactly as intended.
We allowed ourselves a moment of relief. A decade of learning, building, failing, and rebuilding had culminated in this release. The product was solid. We were ready.
Last week, my colleague Rendani and I found ourselves in Berlin's nhow hotel, surrounded by about 250-300 people who share our passion for Domain-Driven Design (DDD), Event Sourcing, and thoughtful software architecture. KanDDDinsky 2025 marked our first time attending this conference – not just as participants, but as sponsors and exhibitors for EventSourcingDB.
Golo: Frank, you are one of the managing directors at Digital Frontiers and also one of the architects and main developers of OpenCQRS. Over the past months we've seen a lot of interest in the framework, especially now with version 1.0 out. Some of our customers have even been building production systems with the release candidate for quite a while already, which shows how stable and usable it has been early on. Before we dive into details, let's start at the very beginning: can you tell us a bit about how OpenCQRS came to life? What triggered the idea and what gap were you trying to fill?