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 operationally in the guide on auditing the event store.

Here's the problem. The moment you allow yourself to overwrite a payload field, "the log says X" stops being proof of anything. A tamper-evident history whose own keepers tamper with it on purpose is just a database with extra ceremony. Worse, the hash chain will tell on you: change a stored event and the chain breaks, which is precisely the signal an auditor is trained to distrust. You don't get a clean redaction; you get a visible scar that says "something here was altered after the fact."

So the field overwrite doesn't just redact one email. It downgrades the entire audit trail from "provable" to "probably accurate, unless someone edited it." For the use case that very likely justified the whole approach, that's not a minor concession.

Caching, Snapshots, and Replays Assume the Past Holds Still

The second casualty is less obvious but far more pervasive. Much of what makes an event-sourced system fast and flexible rests on a quiet assumption: replaying the same events always produces the same state.

That determinism is what lets you build read models, or projections, on demand and actually trust them. You can throw a projection away and rebuild it, run several differently shaped views off the same stream, and add a new one next year from history that's still intact – we explored just how many shapes those views can take in The Read Model Zoo. The same assumption is what makes snapshots safe: a snapshot is only a cached fold over a prefix of the stream, valid precisely because that prefix never changes. EventSourcingDB even realizes snapshots through events rather than a separate store, which works only because the events beneath them never move.

Now mutate one event in the middle of the stream. Every projection you built before the change was derived from data that no longer exists. Every snapshot taken after that point folds in a value that has since been rewritten. Every cache keyed on the old history is now silently wrong – and nothing tells you. The events still load, the system still runs, the numbers are just quietly off.

You can no longer answer "if I rebuild from scratch, do I get the same result I had yesterday?" with a confident yes. You've traded a system whose derived data is correct by construction for one where every cache and every snapshot is a question mark you have to reason about by hand.

Time Travel Needs a Past That Stayed Put

The third loss is the one teams mourn most once they've tasted it. Because an event-sourced system keeps every fact, you can reconstruct the exact state of the world at any moment in the past. "What did this account look like the instant before the disputed transaction?" becomes a query, not an archaeology project.

This is extraordinary for debugging. When something goes wrong in production, you don't theorize about the state that led to it – you rebuild that state and look at it directly. The bug stops being a mystery and becomes an observation. It's also what makes "what if" analysis possible: replay history through a new rule and see how the outcome would have differed.

But time travel only works if the past stayed put. The moment you've overwritten fields after the fact, the past you reconstruct is the edited past, not the one your system actually lived through. You'll rebuild a state that never existed, debug against a history that was retouched, and draw conclusions about an incident from data that was changed after the incident. The single most powerful debugging tool you had now lies to you, politely and without warning.

You Probably Don't Have to Choose

Here's the part we most want teams to hear: the deletion problem is real, and it deserves a real solution. GDPR's right to erasure isn't optional, and immutable storage genuinely makes it harder. We're not waving that away. What we're questioning is the assumption that overwriting events is the only way out – because it's actually the most expensive one.

The cheapest fix is to not write the personal data into the event in the first place. Store a reference – a user ID, an opaque token – and keep the personal data in a conventional store where you can update or delete it freely. Erasing a person then means deleting one row over there; the event stream, which only ever held a reference, stays intact and truthful. We made the broader version of this argument in It's None of Your Business and the concrete version in Don't Put That PDF in Your Event: events are for facts, not for payloads you'll later wish you could take back.

When the data genuinely must live inside the event, there's still a technique that preserves immutability: crypto-shredding. You encrypt the sensitive fields with a per-subject key, store only the ciphertext in the event, and keep the key elsewhere. To erase that person, you destroy their key. The event stays byte-for-byte unchanged, so the hash chain holds, replays stay deterministic, and the audit trail stays provable – but the protected data becomes permanently unreadable. You satisfy the erasure request without rewriting a single fact.

Both approaches keep the rule intact, which is exactly why they keep the benefits intact. We've written up the trade-offs, including when migration-based redaction is the right tool, in our GDPR compliance guide – worth a read before you commit to any deletion strategy. The point is simply this: mutating events to comply is usually a false economy. You spend your audit trail, your reproducibility, and your time travel to solve a problem that has cheaper solutions costing you none of them.

Adapt With Your Eyes Open

Come back to that one small exception. The day it's granted, overwriting a single field to satisfy a deletion request feels like a pragmatic compromise, a minor concession to reality. What we hope is clearer now is the size of the bill stapled to it. That one edit doesn't cost you a field. It costs you the provable audit trail, the reproducible caches and snapshots, and the ability to trust a reconstructed past – three of the headline reasons to choose Event Sourcing at all, given up to solve a problem that didn't require surrendering any of them.

None of this means you can't adapt Event Sourcing. You can, and sometimes you should. Just as with Scrum, the freedom to change the practice was never the issue. The issue is expecting the benefits of a discipline you've opted out of. Keep the rule and you keep what the rule buys you. Break it and you should break it deliberately, knowing precisely which guarantees walk out the door with it – and ideally reaching for a technique that lets you keep both.

So before you grant yourself that one small exception, ask which of these benefits you were counting on. If the honest answer is "none of them," then adapt away with a clear conscience. If the answer is "several," the exception is far more expensive than it looks.

Modeling personal data in an event-sourced system is exactly the kind of decision that's cheap to get right at design time and painful to retrofit later. If you're weighing these trade-offs for your own architecture, we'd genuinely enjoy thinking them through with you – just write to us at hello@thenativeweb.io.