Skip to content

Perspectives

All Models Are Wrong, Some Are Useful

"All models are wrong, but some are useful." The statistician George Box wrote this in 1976, and it remains one of the most underappreciated truths in software engineering. We spend weeks, sometimes months, trying to build the perfect domain model before writing a single line of code. We draw diagrams, debate naming, argue about boundaries. The intention is good: get it right upfront so you don't have to fix it later.

But the pursuit of the perfect model is itself a trap. Models are always incomplete, always a simplification of a reality that is too complex to capture fully. The question was never whether your model is right. It was always whether your model is useful enough to start, and whether you know how to evolve it when reality teaches you what you missed.

It Was Never About the Database

We build a database. We spend our days thinking about storage engines, query languages, and wire formats. We obsess over write throughput, replay performance, and consistency guarantees. This is what we do, and we care deeply about getting the technical details right.

But when we look back at the most impactful conversations we've had with teams adopting Event Sourcing, they were never about technology. They were about how people work together. About how a team that had been talking past each other for months suddenly found a shared vocabulary. About how a business process that had been invisible for years became something everyone could see, discuss, and improve. That is the story we want to tell today.

Consistency Is a Business Decision

You have probably heard of eventual consistency. The short version: in a distributed system, when data changes in one place, other parts of the system might not see that change immediately. For a brief moment, different components have different views of the truth. Eventually, they all catch up. Eventually, they all agree. But not instantly.

This concept makes many developers nervous. "Eventually consistent" sounds like "temporarily wrong." It sounds like a bug waiting to happen. In German, it gets even worse: "eventual consistency" is often translated as "eventuell konsistent," which means "possibly consistent," implying the data might never be correct. No wonder people reach for stronger guarantees.

But "eventual" in English means "ultimately" or "in the end," not "possibly." Eventual consistency means the system will become consistent, given enough time. The question is not whether consistency happens, but when. And here is the uncomfortable truth: your system is already eventually consistent. You just have not admitted it yet.

Three Conversations Worth Having With Your CTO

You have built something good. The architecture is solid, the code is clean, the team knows what they are doing. But when you suggest a foundational change, like rethinking how data is stored, the conversation stalls. "What is the business case?" "What problem does this solve?" Fair questions. Hard to answer in a hallway conversation.

This post is for that conversation. Not the technical one (you already understand that), but the business one. Three problems that cost real money, that your CTO cares about even if they do not know the technical details, and that have solutions your team can implement.

Soft Delete Is a Workaround

Three weeks ago, Alex Buchanan published a thoughtful blog post about soft delete strategies. In "The challenges of soft delete", he describes the problem carefully and offers four creative solutions. His analysis is thorough, his examples concrete, and his engineering instincts sound.

His analysis is correct, his solutions well considered. But all four strategies have something in common: they optimize a problem that does not exist with a different architectural approach.

What Aviation Teaches Us About Auditing

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.

Don't Kill Your Users

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.

One Database to Rule Them All

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

... And Then the Wolf DELETED Grandma

Last week, I had the pleasure of speaking at the Software Architecture Gathering 2025 in Berlin. The conference is organized by the iSAQB (International Software Architecture Qualification Board) and brought together around 400 attendees from numerous countries. My talk, titled "... And Then the Wolf DELETED Grandma," explored why CRUD falls short when modeling real-world processes, and about 120 people joined me in the room to discuss fairy tales, databases, and the limits of our industry's favorite paradigm.

The response was overwhelming. Conversations continued long after the session ended, and many attendees shared similar frustrations with CRUD in their own projects. This post is the written version of that talk: for everyone who couldn't be there, and for those who were and wanted to revisit the ideas.

Event Sourcing is Not For Everyone

A few days ago, Martin Dilger published an article on LinkedIn titled "When Event Sourcing Doesn't Make Sense (And How to Know the Difference)". It's a thoughtful piece that addresses an important question: when should you not use Event Sourcing? The article sparked several private conversations, and one in particular revealed a confusion I see far too often.

Someone described a ride-sharing application where a driver continuously transmits GPS coordinates while traveling to pick up a passenger. The question was: are these GPS updates events? And if so, should they be stored using Event Sourcing? The answer reveals a fundamental distinction that many teams overlook: not everything that looks like data is an event, and not every event belongs in an event-sourced system.