Your core system is event-sourced. A customer exercises their right to erasure. The events are immutable by design. What do you do?

What the interviewer is testing

Whether you know the standard resolution to the conflict between immutability and erasure.

Why the alternatives fail

Rewriting the stream destroys the properties event sourcing exists for: the log is no longer an unalterable record, every downstream projection's offsets are invalidated, and any consumer that has already processed the removed events is now inconsistent. It is also enormously expensive at scale.

Refusing is not available. Technical architecture is not a lawful basis for retaining personal data, and "our design does not permit it" is precisely the answer regulators have rejected.

Crypto-shredding

Encrypt each subject's personal data with a per-subject key, held in a key management service. The event stream stores ciphertext. To erase, delete the key.

The events remain, the stream's structure and offsets are untouched, every non-personal aspect of the history is preserved for audit and reconstruction, and the personal content is irrecoverable.

The design detail that decides whether it works

Separate personal from non-personal data within the event. An event should carry the business facts in the clear — an order was placed, for this amount, at this time — and only the personal attributes encrypted. Otherwise erasure destroys the operational history too, and projections cannot be rebuilt.

That structure must be decided at design time. Retrofitting it into an existing event store means rewriting the events, which is the thing you were trying to avoid.

The rest of the estate

Erasure applies everywhere, not just the event store: projections and read models, search indexes, caches, analytical copies, and logs. Crypto-shredding covers the derived stores too if they hold the same ciphertext; those holding decrypted copies need their own deletion.

For backups, the accepted regulatory position is pragmatic: they need not be individually edited, provided deletion is reapplied on restore and retention is bounded. That replay step is usually absent and should be built.

What a strong answer adds

Noting that erasure is not absolute — legal retention obligations and legal hold override it — so the architecture must express "retain because required" as a distinct, auditable state rather than treating every request as unconditional.

Common weak answers

Deleting the projection only, leaving the source. Claiming the events are anonymised because names were removed, when the identifiers still link.