Immutable Store Erasure Conflict
The direct contradiction between architectures designed never to forget and obligations requiring data to be removed, which must be resolved in the design rather than in policy.
Event sourcing, append-only ledgers, write-once compliance storage, blockchain and immutable backups all derive their value from being unalterable. Erasure obligations require alteration. The conflict is genuine and cannot be resolved by asserting that one takes precedence.
Four resolutions exist, and each is a design decision made early or not at all. Separate identity from event, so the immutable record holds a reference and the personal data lives in a mutable store that can be deleted — after which the events remain as facts carrying no identifying content. Cryptographic erasure, where per-subject keys are destroyed and the ciphertext becomes permanently unreadable wherever it exists. Rewrite by replay, reprocessing the log without the subject and swapping, which is correct and expensive. A retention position, arguing that a specific legal obligation to retain overrides erasure for that dataset — which is legitimate where it applies and is not a general answer.
The one that does not work is planning to delete from the immutable store later. The reason organisations end up there is that the choice was never made: the architecture was selected for its immutability and the obligation was assessed afterwards, by which point the only remaining options are the expensive ones.