Design a GDPR 'Right to be Forgotten' System

What's really being asked

This question tests your ability to think beyond a simple DELETE statement. The interviewer is assessing if you understand the complexities of data lifecycle management in a modern, distributed architecture. They want to see you design a system that is not just functional but also auditable and verifiable, which is the cornerstone of regulations like GDPR. Can you handle immutable data (S3), transactional data (Snowflake), and ephemeral data (Redis) in a single, coherent process?

The full answer

An effective answer addresses four key areas in order. First, a Metastore Index: you cannot delete what you cannot find. Propose a centralized index (e.g., DynamoDB, RDS) that maps a user ID to every physical location their data resides, such as S3 object URIs and row numbers, database primary keys, etc. This index must be updated as data is ingested. Second, an Orchestration Workflow: describe a state machine (like AWS Step Functions) to manage the multi-step deletion process. This includes querying the index, handling approvals, dispatching deletion tasks, and reporting. Third, Storage-Specific Deletion Logic: explain how you'd handle each layer. For S3's immutable files, this means rewriting objects without the user's data, not deleting a 'row'. For Snowflake, it's running a DELETE but also considering time-travel. For Redis, it's a simple DEL command. Fourth, Verification and Auditing: the process must generate proof. This means logging all actions, storing approval records, and creating a final 'Certificate of Deletion' for compliance.

The mistakes people make

A candidate is failing if they focus only on the application database, saying "I'll just delete the user from the users table." This ignores 90% of the problem. Another major red flag is proposing a "search and destroy" approach without an index; scanning petabytes of data for every deletion request is operationally and financially infeasible. Suggesting you can simply delete a row from a Parquet file on S3 demonstrates a fundamental misunderstanding of data lake storage formats. Finally, forgetting the verification step is a critical omission; the goal is to prove deletion to a regulator, not just perform it.

What usually comes next

Be prepared for follow-ups like: "How do you handle backfills for existing data that was never indexed?" (Answer: a one-time batch job using Spark/EMR to scan and populate the metastore). Or, "How do you manage the cost of rewriting massive S3 objects for a single user deletion?" (Answer: batching deletion requests, using compaction strategies). And, "What about data in backups?" (Answer: policy dictates backups must expire on a schedule that aligns with regulations, or a process must exist to purge from them).

A concrete example

A user requests deletion via an API call. This triggers an AWS Step Function. The first Lambda queries a DynamoDB metastore to find all data locations for that user ID. The metastore returns a list of S3 URIs, Snowflake table rows, and Redis keys. The workflow pauses for an optional manual approval step. Upon approval, parallel tasks are dispatched: one Lambda rewrites the affected S3 Parquet files, another issues a DELETE to Snowflake, and a third issues a DEL to Redis. After all tasks succeed, the metastore entries are deleted and a final PDF report is generated and stored in an audit S3 bucket.