Prompt and suitable context
A user asks to delete personal data while the system retains operational, analytical, and disaster-recovery copies. Some records have already been aggregated and some downstream systems are operated by processors. Explain request authentication, impact discovery, propagation, backup handling, recovery, and the external status response.
This question tests lineage, asynchronous workflows, idempotency, retention policy, and evidence. Privacy and legal teams define the applicable exemptions; engineering should implement the approved policy rather than invent one.
What the interviewer evaluates
The interviewer wants separate states for “request accepted,” “live systems erased,” “backups beyond use,” and “all exemptions recorded.” European and UK guidance describes erasure exceptions and says backup copies cannot continue to be used; the engineering design must make scope and completion explicit.
A strong answer starts with a catalog and subject-identifier map, drives every store with versioned deletion events, and finishes with independent verification. A single SQL DELETE cannot cover lake files, caches, indexes, snapshots, or processors.
Clarifications to ask first
- How is the requester authenticated, and how are delegated requests and mistaken deletion prevented?
- Which fields are personal data, and which aggregates are no longer reasonably identifiable?
- Are there legal holds, financial-record duties, or dispute-related exemptions?
- Does the catalog list every downstream table, snapshot, backup, and processor?
- Is the external promise immediate deletion, completion within a period, or first putting data beyond use?
A 30-second answer framework
“I would authenticate the request and create an immutable deletion case, then use a data catalog to resolve subject identifiers and every processing system. A versioned, idempotent deletion event drives each downstream response. Live data is erased; backups are isolated and prohibited from restore or analysis until their retention rotation. Legal holds and irreversible anonymization are recorded separately. Independent queries, tombstone manifests, downstream acknowledgements, and audit logs prove scope, while failed tasks can be retried safely.”
Step-by-step deep answer
Step 1: Build the catalog and erasure scope
Maintain a subject-key map for account ID, tenant ID, pseudonymous event IDs, and processor-specific IDs. The catalog records source, purpose, retention, downstream tables, files, indexes, caches, snapshots, backups, and processors.
Freeze new processing for the subject while the case runs so the pipeline does not recreate the same data. For every asset, choose physical deletion, field clearing, irreversible anonymization, access blocking, or legal hold and record the basis.
Step 2: Create an idempotent erasure workflow
After identity verification, create caseId, subjectId, policy version, and a unique requestKey. Publish through a transactional outbox; consumers use caseId + assetId as their idempotency key.
{
"type": "SubjectErasureRequested",
"caseId": "erase_20260729_001",
"subjectId": "user_123",
"policyVersion": "2026-07",
"requestKey": "user_123:20260729:001"
}Each consumer writes state before a retryable action or uses an idempotent constraint. A duplicate event must not erase a new account or turn a successful state into failure.
Step 3: Handle each storage layer
Delete or make the subject unrecoverable in OLTP, then keep only the minimum processing record in the event bus and filter the subject from replay and re-materialization. In the lake and warehouse, update partitions, tables, SCDs, materialized views, and snapshots; immutable files may need delete manifests, rewrite jobs, or a table format with delete semantics.
Search indexes, caches, reverse ETL, and processors need independent acknowledgements. “The primary database is clean” is not global completion. Keep an aggregate only when the approved policy permits it and the subject is not reasonably re-identifiable; otherwise recompute or subtract its contribution.
Step 4: Handle backups and legal holds
Evaluate exemptions first: legal obligations, litigation holds, or approved public-interest research may require retention. An authorized policy must define scope, expiry, and reviewer. For backups without an exemption, do not use them for production restore or analysis; if they cannot be overwritten immediately, isolate and encrypt them, block reads, and delete them during rotation.
The external status must explain the schedule for live systems, backups, and processors. Do not promise that one button instantly erased every historical medium.
Step 5: Verify, observe, and reconcile
Store status, attempt count, last error, evidence digest, and completion time for each asset. An independent verifier derives checks from the catalog: no live-table subject rows, no index hits, snapshots no longer serving old data, downstream event acknowledgements, and backups in a beyond-use state.
Track pending cases, per-asset latency, retry rate, permanent failures, exemptions, processor acknowledgements, and sampled verification failures. Completion notifications should state scope and exceptions, not return only a Boolean.
High-quality sample answer
“I would turn the deletion request into an auditable case. After authentication, create the subject key, policy version, and unique request key, then expand OLTP, event streams, lakehouse, warehouse, BI, indexes, caches, backups, and processors from the catalog. A transactional outbox publishes a case-scoped deletion event; every asset handles it idempotently and reports status.
Erase or recompute live data, materialized views, and indexes. Retain aggregates only when they are not reasonably re-identifiable and policy permits it. Backups cannot be used for restore or analysis; if immediate overwrite is impossible, isolate them as beyond use and remove them on rotation. Legal holds receive separate approval, expiry, and review. Independent catalog-driven queries, downstream acknowledgements, and audit summaries prove scope, and retries cannot erase newly created data.”
Common mistakes
- Delete only OLTP → lake, index, snapshot, or processor data may remain → expand every asset from the catalog and collect acknowledgements.
- Treat deletion as a one-shot script → partial failure becomes unprovable → use an idempotent case, state machine, and retries.
- Assume every aggregate is anonymous → sparse dimensions can re-identify a subject → assess identifiability or recompute.
- Delete backup files immediately → recovery, audit, or legal retention can break → isolate, block use, and rotate under policy.
- Promise immediate total deletion → media and exemptions may make it impossible → state live, backup, and exception timelines.
- Log full personal records for debugging → logs become hidden copies → keep only case, asset, outcome, and minimal error summaries.
Follow-up questions and responses
Follow-up 1: How do you prevent deleting the wrong user with a duplicate name?
Require an authenticated session, second confirmation, or equivalent identity proof and use an immutable internal subject ID, never an email or display name. High-risk tenants can add approval and notification.
Follow-up 2: What if the event is already in an immutable log?
The log should no longer be used by business consumers. Add a deletion or suppression manifest and filter the subject during replay and materialization. If personal fields remain, rewrite, isolate with encryption, or destroy them on the approved rotation schedule.
Follow-up 3: Can an aggregate report be retained forever?
Do not decide from the word “aggregate.” Assess small groups, sparse dimensions, and combinations with external data. Retain only when reasonable re-identification is not possible and policy allows it; otherwise recompute, subtract, or erase.
Follow-up 4: How do you prove backup data is deleted?
Record backup generations, retention, isolation, read controls, and rotation times, then sample after rotation. When immediate overwrite is impossible, proving the copy is beyond use is more accurate than claiming every physical bit disappeared immediately.