We'll Take the Benefits, Hold the Rules - EventSourcingDB

Skip to content

Initializing search

Getting Started

Fundamentals

Deployment and Operations

Reference

Client SDKs

Extensions

MCP Server

Best Practices

Implementation and Development

Data Management and Performance

Operations, Compliance and Infrastructure

Common Issues

Blog

Categories

Privacy Policy

Legal Notice

We'll Take the Benefits, Hold the Rules¶

There's a moment that shows up in Event Sourcing projects again and again. The design is going well, the team is sold on the idea, and then a single hard requirement surfaces: GDPR's right to erasure. All at once, storing events immutably looks less like a feature and more like a liability. So the team grants itself one small exception – when someone asks to be deleted, they'll reach into the stored event and overwrite the offending field, turning an email address into "redacted". One small edit, applied rarely, to a system that is otherwise append-only.

It sounds harmless. It even sounds responsible. But that one exception quietly cancels a large part of the reason they chose Event Sourcing in the first place, and they likely won't notice until the day they need one of the guarantees that no longer holds. Because the benefits of Event Sourcing aren't a menu you order from. They all hang on a single thread, and that field overwrite cuts it.

We've Seen This Before¶

We've watched this pattern play out for years, and not only with Event Sourcing.

Rewind ten or fifteen years to when teams everywhere were adopting Scrum. They wanted the benefits: faster feedback, more predictable delivery, happier and more autonomous teams. But some of the practices were uncomfortable, so they trimmed them. Retrospectives got dropped because there was never time. The Product Owner doubled as Scrum Master because hiring for both roles seemed wasteful. Sprints were allowed to "breathe" whenever a deadline slipped. Each cut looked perfectly reasonable in isolation, and plenty of them genuinely were.

Because here's the thing: adapting a method to your context isn't the mistake. There's nothing sacred about any practice, and shaping a discipline to fit how you actually work is usually the right instinct, not the wrong one. The question that's easy to skip past in the moment is a quieter one. When you change the thing, what changes with it? What do you gain from the adaptation, and what quietly leaves along with the part you removed?

That question is the heart of this post. The trap isn't adapting a discipline – it's expecting the unchanged payoff after you've changed the thing that produced it. You can keep the rules and keep the benefits, or drop the rules and accept the loss, but you can't drop the rules and keep the benefits. That bargain was never on the table.

Event Sourcing invites exactly that question, and the field-overwrite exception is a textbook case. So let's look at what's actually being traded away.

One Rule Holds It All Up¶

Strip Event Sourcing down to its core and you find a surprisingly small idea. You don't store the current state of your data. You store the sequence of facts that led to it, and you never change a fact once it's recorded. That's the whole thing. Events are immutable. Append-only. What happened, happened.

Everything people love about Event Sourcing grows out of that one rule. The trustworthy audit trail, the ability to rebuild any past state, cheap and disposable caches, time travel for debugging – none of these are separate features that the database bolts on the side. They are consequences of immutability. Take immutability away and they don't degrade gracefully; they stop being true.

This is the part that's easy to miss when you grant yourself "just one small exception." You picture removing a single item from a feature list. What you're actually removing is the foundation that several of those features silently stand on. The features don't know about your good intentions or how rarely you'll use the exception. They only know whether the past can change.

Let's trace what actually leaves the building when you overwrite that one field.

Auditability Was the Whole Point¶

Many teams reach for Event Sourcing precisely because they need a history they can trust. Regulated industries, financial systems, anything where "what happened, and when?" must be answerable and defensible months or years later – these are the classic cases, and they're often the reason the idea gets approved at all.

EventSourcingDB strengthens that history with hash chaining: each event carries a cryptographic hash that incorporates the hash of its predecessor, forming a tamper-evident chain that behaves much like a blockchain. We've written about why that matters in What Aviation Teaches Us About Auditing , about how you can prove a specific event existed without revealing its contents in Proving Without Revealing: Merkle Trees , and about how to put it to work...