An event-sourced system keeps an immutable log. A subject requests erasure. How is this resolved?

Why it is a genuine conflict

The immutable log's value comes from being unmodifiable — it is what makes the history reconstructable and the audit defensible. Rewriting it to remove a subject's data destroys exactly the property the design exists for, and in an event-sourced system it invalidates every downstream projection.

The resolutions, in order of preference

• Crypto-shredding. Personal data in events is encrypted with a per-subject key held outside the log. Erasure destroys the key, rendering that subject's content unrecoverable everywhere at once — including in backups — while the event structure, ordering and non-personal content remain intact for audit.
• Keep personal data out of the log entirely, storing a reference to a mutable store. The log records that an event occurred and to whom by reference; the referenced record is erasable. This is the cleanest design and it must be chosen before the log exists.
• Retention obligation prevails, where a legal basis requires keeping the record. The request is refused with the basis stated, which is a legitimate outcome and needs to be a supported path rather than an exception.
• Log rewriting with re-projection, which is technically possible, invalidates the immutability guarantee, and is expensive enough that it is a last resort.

The design decision that determines the cost

Whether personal data enters the immutable log at all. Deciding this at design time costs nothing. Discovering it when the first erasure request arrives means retrofitting encryption to a log that already exists, which requires reprocessing all of it.

The wider point

Every immutable store faces this: audit logs, backups, blockchains, data warehouses with append-only history. The mechanism is the same — separate the personal content from the structural record and make the personal part independently destroyable — and it works only if it was designed in.