The Customer Who Asked to Be Forgotten

The story

An email arrived with the subject line “Right to Erasure Request.” A customer in the EU wanted their personal data deleted — all of it. Their name, their email, everything Frontrow held. This wasn’t a feature request; it was a legal obligation with a deadline and a fine attached.

Mara went to delete the customer’s data and ran straight into the wall Frontrow had spent two years building on purpose. Every meaningful thing that had ever happened was stored as an immutable event. That immutability was a feature — it gave them audit trails, the ability to rebuild read models, the answer to “what happened?” But the customer’s name was baked into hundreds of those events, and the whole architecture was designed so you couldn’t go back and change them.

“So the property that makes our audit trail trustworthy,” Tobi said, “is the same property that might get us fined for not deleting someone’s name.” Two of the things Frontrow cared most about — provable history and customer privacy — were apparently in direct conflict. Mara needed a way to make personal data unrecoverable without rewriting an append-only log she’d promised never to rewrite.

Why this is hard the traditional way

“Delete this person” and “never change the historical record” sound mutually exclusive, and in most event-sourced systems they are. Rewriting events to scrub a name breaks immutability — and once you’ve shown you’ll rewrite history “just this once,” every audit guarantee you’ve made is suspect. But not deleting it isn’t an option either; regulators don’t accept “our architecture made it inconvenient” as a defense.

The naive workarounds are worse. Deleting whole event streams takes the customer’s non-personal history with it and can corrupt aggregates that referenced them. Maintaining a separate “but actually delete from here” store means you’ve quietly recreated the very copies-of-personal-data problem you were trying to solve.

How Relay changes the ending

Relay supports crypto-shredding. Instead of storing personal data in the clear inside events, you encrypt it with a per-subject key. The events stay immutable — not one byte is rewritten. To “erase” the person, you destroy their key. The ciphertext remains in the log, but it’s now permanently unreadable: data that mathematically cannot be recovered.

// Personal fields are stored encrypted with a key unique to this subject.
// "Forgetting" them is one operation — destroy the key.
await cryptoShredder.ForgetSubjectAsync(customerId);
// Every event referencing them stays in place, but their personal data
// is now undecryptable noise. Audit history intact; person erased.

This is the rare clean resolution to a genuine conflict. The audit trail keeps its integrity — the events are untouched, the sequence is intact, replays and rebuilds still work. And the customer is genuinely, irreversibly erased, because the key that made their data readable no longer exists anywhere. Provable history and the right to be forgotten, at the same time.

What it costs you to ignore this

• “We can’t easily delete it” is not a legal defense. GDPR, CCPA, and friends come with deadlines and fines, not suggestions.
• The fix can be worse than the problem. Deleting event streams to comply can corrupt your data and destroy non-personal history.
• Immutability and privacy fight unless you design for both. Discover the conflict during an erasure request and you’re solving it under a clock.
• Trust cuts both ways. Customers who can’t get erased, and auditors who find rewritten history, both walk away.