Design how your lakehouse handles "right to be forgotten" requests: a customer asks you to delete their personal data, and it must be gone from every table within 30 days.

Treat deletion as a pipeline, not a manual task. Requests go into a deletion requests table; a scheduled job deletes the customer from bronze first and lets the deletes flow to silver and gold; table maintenance then removes the deleted rows from old files and history; and a report proves each request was completed. Design the data so personal fields are few and easy to find, and remember that the data also lives outside the lakehouse.

1. Where personal data hides in a lakehouse

• Current tables in every layer, and copies made by people (exports, sandbox tables).
• Old table versions: a Delta DELETE writes new files, but the old files still hold the rows until VACUUM removes them, 30 days of history by default.
• Deletion vectors: deleted rows are marked, not physically removed, until the files are rewritten.
• Change feeds, Kafka topics, raw files and backups upstream and downstream.
• Logs, ML training sets and models built from the data.

2. Shrink the problem by design

• Use a surrogate key (customer_id) everywhere, and keep names, emails, phones and addresses in a few PII tables. Deleting those rows severs the link; facts such as order amounts can stay.
• Tag PII columns in the catalog so you can list every table that holds them.
• Pseudonymise in analytics layers: gold tables rarely need names at all.

3. The deletion pipeline

deletion_requests (customer_id, requested_at, status)
   ──▶ daily job:
       1. DELETE from bronze PII tables and raw events for those IDs
       2. propagate to silver and gold (MERGE/DELETE, or refresh materialized views)
       3. REORG ... APPLY (PURGE) where deletion vectors are on
       4. VACUUM within the retention window
       5. mark request done, with table names and row counts

• Bronze first, so a later rebuild from bronze cannot bring the person back.
• Streaming tables expect append-only sources. Delete from the source and from the streaming table, and set the streaming read to skipChangeCommits so it ignores the delete commits.
• Retention fits the deadline: with 30 days to comply, a 7-day VACUUM retention gives you time to run the job weekly and still finish.

4. Outside the lakehouse

• Set Kafka retention and raw file lifecycle rules shorter than the deadline, or delete there too.
• Backups: either expire within the deadline or keep a suppression list that is applied whenever a backup is restored.
• ML: record which training sets included the person, and retrain on schedule without them.

5. Prove it

An audit table per request: what was deleted where, when, and by which job run. Run a monthly check that searches every PII-tagged table for completed IDs. Zero hits is the evidence regulators and auditors ask for.

What interviewers want: knowing that DELETE alone leaves data in history and deletion vectors, a request-driven pipeline starting at bronze, purge and vacuum with retention matched to the deadline, surrogate keys to limit where PII lives, upstream copies and backups, and an audit trail.