Design the mechanism by which a deletion request propagates through a system with a warehouse, a search index, backups and three third-party processors.

What is being tested

Whether you design a mechanism rather than a runbook, and whether you handle the two hard cases — backups and immutable stores.

The mechanism

1. A deletion request becomes a durable record, not an action. It has a state machine — requested, in_progress, verified, complete — and a deadline derived from the regulatory window.

2. Publish a SubjectErasureRequested event. Every system holding personal data subscribes and acknowledges when it has completed. Acknowledgement is the important part: without it you cannot prove completion, and proving completion is the actual obligation.

3. Each subscriber implements its own deletion, because only it knows its data model. The primary store hard-deletes or anonymises; the search index removes the document; caches invalidate; the warehouse deletes rows (which requires a table format supporting row-level deletes — worth knowing before you need it).

4. Third-party processors are called through their deletion APIs, with the same acknowledgement requirement. Where a processor has no API, this becomes a manual task with a tracked SLA, and that is a procurement finding worth raising.

5. Verification. After acknowledgements, a job re-queries each store for the subject's identifiers and alerts if anything is found. A deletion mechanism without verification is an assertion.

6. Completion recorded, with evidence, because you will be asked to demonstrate it.

The two hard cases

Backups. You cannot practically delete one record from a backup without invalidating it. The accepted position is:

• A documented retention window — backups roll off within N days, stated in the privacy notice.
• A suppression list that survives independently, consulted after any restore, so deletions are re-applied. This is the mechanism people forget, and without it a restore silently resurrects deleted people.

Immutable stores — event logs, append-only ledgers, audit trails. Crypto-shredding: personal data encrypted per subject, key destroyed on erasure. The events remain structurally intact and the personal fields become permanently unreadable. This must be designed in from the start; data already written in plaintext cannot be shredded.

The prerequisite

A maintained data inventory and classification. If you cannot list where personal data lives, you cannot delete it, and no mechanism helps. This artefact is the difference between a one-day response and a two-week archaeology exercise, and it must exist before the first request arrives.

The conflict to resolve explicitly

Retention obligations and erasure rights apply to the same customer. Resolve field by field: delete or anonymise identity attributes, retain the financial record with a pseudonymous reference. Record-level thinking makes this look unresolvable; field-level thinking resolves it.

What a strong answer adds

That the cheapest data to delete is data never collected. Minimisation — sampling telemetry, aggregating rather than retaining raw events, declining to log request bodies — removes cost and legal exposure permanently rather than managing them.