All work
Architecture PatternRegulated data / privacy

Erasing a person’s data from a history that is never rewritten

Encrypt each person’s data with their own key. Destroying that key makes their data unreadable, with the history left intact.

Context

Some systems keep a permanent history: every change is recorded as a new entry, and past entries are never edited or deleted (an approach called event sourcing). That history is valuable for auditing and for understanding how a record reached its current state. When the system holds personal data, it can also be subject to privacy laws that give people a right to have their data erased.

The problem

The two pull in opposite directions. A history that is never rewritten can’t simply have a person deleted from it, yet an erasure request may still have to be honored.

Constraints

  • Past entries are never rewritten or deleted.
  • After erasure, a person’s data must not be recoverable.
  • Personal data must never travel unencrypted on messages leaving the system.

Approach

Rather than storing personal data as plain text and trying to remove it later, each person’s data is encrypted with a key unique to them (a technique called crypto-shredding). The history holds encrypted values, not names or birth dates. Erasing someone means destroying their key, which makes the data about them unreadable without touching a single past entry.

For erasure to hold, keys are kept out of backups and copies, and no readable copy of the data is kept elsewhere, such as in reports, caches, or other systems. A build-time check helps catch personal data on outgoing messages before release.

The pattern works alongside an organization’s own legal and compliance guidance.

Key engineering decisions

  • One key per person

    Destroying a single key makes everything about that person unreadable at once, across every entry that references them.

  • No readable personal data stored

    Only encrypted values are stored in the history and the views built from it, so once the key is gone there is nothing readable left there.

  • Checked at build time

    A check fails the build if it finds personal data on an outgoing message, so that kind of leak is caught before release.

What it demonstrates

That a permanent history and the right to erasure can coexist: the person’s data becomes unreadable, and the history stays intact.

Technologies

  • Event sourcing
  • Crypto-shredding
  • CQRS
  • Build-time guard

Related expertise

Working through something similar?

Tell us what you have in mind. We’ll work out the next step together.

Start a Conversation