Right to Erasure

This is the requirement that most sharply constrains architectural choices, because a family of designs that engineers have good reasons to favour are structurally hostile to deletion: event sourcing, immutable logs, append-only data lakes, blockchain, and backups by definition.

The tension is genuine. An event log's value comes from being an unalterable record of what happened; erasure requires altering it.

The techniques that resolve it, in order of preference. Crypto-shredding: encrypt each subject's personal data with a per-subject key, and delete the key. The ciphertext remains in the immutable structure, the plaintext is unrecoverable, and this is now the standard answer for event-sourced and log-based systems. Separation: keep personal data in a mutable store and reference it by identifier from the immutable one, so the events retain their structure and lose their personal content. Tombstone and compaction, where the storage format supports rewriting.

For backups the accepted position across most regulators is pragmatic: backups need not be individually edited, provided deletion is applied on restore and retention is bounded — which requires the restore process to actually replay pending erasures, and that step is usually absent.

The counterweight to know: erasure is not absolute. Legal retention obligations, legal hold and certain other lawful bases override it, and the architecture must therefore express retain because required as a distinct state rather than treating every deletion request as unconditional.