A system is event-sourced. A customer exercises their right to erasure. The event log is immutable. How do you comply?

What is being tested

Whether you know the standard reconciliation between immutability and erasure, and whether you understand that it must be designed in rather than retrofitted.

Why the obvious answers fail

Rewriting the log destroys the property that made event sourcing worth having. Hashes and sequence positions change, snapshots are invalidated, any downstream that consumed the old stream is now inconsistent with it, and the audit trail — the entire point — is no longer trustworthy. It is also operationally brutal at any real volume.

Marking as deleted and filtering is a soft delete. The personal data is still there, readable by anyone with database access, present in every backup. Under most privacy regimes that is not erasure, and the fact that a deleted_at column is frequently mistaken for compliance is itself a common and expensive misunderstanding.

Deleting only projections leaves the source data intact and is not erasure at all.

Crypto-shredding

Personal data within events is encrypted with a key held per data subject in a separate key store. Erasure means destroying that key. The events remain, structurally intact, with their sequence and hashes unchanged — the personal fields simply become permanently unreadable.

What survives, which is usually exactly what you want: the shape of history. You still know that an order was placed on a date for an amount, which preserves financial and audit integrity. You no longer know who placed it.

What makes this work — and why it cannot be retrofitted

• Personal data must be segregated within the event payload from the start, so that encrypting it does not encrypt the whole event and make the log unreadable for legitimate purposes.
• The key store is now a critical dependency with its own availability, backup and access-control requirements. Losing keys accidentally is unrecoverable data loss.
• Backups of the key store must honour deletion, or a restore resurrects the data.
• Projections must be rebuilt after shredding, since they contain decrypted copies.
• You must know which fields are personal. This is a data classification problem, and getting it wrong is discovered during an audit.

Data already written in plaintext cannot be shredded. That is the retrofit problem, and the only answers to it are a one-off rewrite or an exemption argument — which is why this decision belongs in the initial design of any event-sourced system holding personal data.

What a strong answer adds

Questioning whether the whole system needed to be event-sourced. Event sourcing is the honest model where history is the domain — ledgers, trading books, regulated approval chains. Applied to a customer profile, it buys little and imports this problem permanently. Scoping event sourcing to the bounded context that needs it, and keeping personal data in a conventional mutable store, avoids the conflict entirely.