Context
An event-sourced system that holds personal data and is subject to privacy law’s right to erasure.
The problem
Event sourcing makes the log the source of truth: only appended to, never edited, never deleted. Privacy law lets a person demand that their data be erased. A permanent record cannot be deleted from, and an erasure request cannot be refused.
Constraints
- Past events are immutable: history is never rewritten or deleted.
- Erasure has to leave a person’s data permanently unrecoverable.
- Personal data must never travel in the clear on events leaving the system.
Approach
Rather than storing personal data in the clear and trying to remove it later, each person’s data is encrypted with a key unique to them and kept out of the log and the read models entirely. The log holds encrypted data, not names or birth dates. Erasing someone means destroying their key: every record about them becomes permanently unreadable without touching a single past event. A build-time check fails the build if personal data ever leaks onto an outgoing event.
Key engineering decisions
One key per person
Destroying a single key makes everything about that person unreadable at once, across every event that references them.
No readable personal data in the log or read models
Only encrypted values are stored, so once the key is gone there is nothing readable left behind.
Enforced at build time
A check fails the build if personal data appears on an outgoing event, so a leak is caught before it can ship.
What it demonstrates
That an immutable history and the right to erasure are not a contradiction: the person is erased, and the history stays intact.