GDPR deletion pipeline

The Problem Statement

Interviewer: "A user clicks 'Delete My Account' on your platform. Under GDPR, you have 30 days to erase all their personal data. But their data is spread across your primary database, Redis caches, Elasticsearch indexes, analytics warehouses, backups, and several third-party processors like Stripe and Segment. Walk me through the full pipeline you would build to guarantee compliance."

This question tests three things: whether you understand that user data is scattered across dozens of systems (not just one database), whether you can design an asynchronous event-driven pipeline that coordinates deletion across all of them, and whether you know the hard edge cases like immutable backups, Kafka event retention, and third-party data processors.

Candidates often lose points here because they treat it as a single DELETE FROM users WHERE id = ? statement. The interviewer wants you to show awareness of the data topology in a real production system, explain why backups are uniquely hard, and offer concrete strategies (like crypto-shredding) for the cases where deletion is physically impossible.

The right to erasure under GDPR Article 17 is not theoretical. Meta was fined 1.2 billion euros in 2023 for data transfer violations. Fines for non-compliance reach up to 4% of global annual revenue. This is a real engineering constraint that shapes system architecture at every company with European users.

Clarifying the Scenario

You: "Before I design the pipeline, let me clarify scope."

You: "When you say 'all personal data,' does that include data shared with third-party processors, analytics pipelines, and backups? Or just primary data stores?"

Interviewer: "Everything. I want the full picture."

You: "Got it. And should I assume a microservices architecture where user data is spread across multiple services, each with their own databases?"

Interviewer: "Yes. Assume at least 10 services have some form of user PII."

You: "One more question. Do we need to prove that deletion happened? Some compliance teams require an audit trail."

Interviewer: "Yes, the audit trail is important. Walk me through how you prove you deleted data without storing the data you deleted."

You: "OK. I will structure my answer in four parts: the immediate soft-delete in the primary database, the async event-driven propagation to all downstream systems, the hard cases like backups and ML models, and the audit trail that proves compliance."

My Approach

I break this into five parts:

1. Where user data actually lives: Map the full data topology before designing a deletion pipeline. You cannot delete what you have not inventoried.
2. Phase 1, immediate soft-delete: Anonymize PII in the primary database within seconds. This stops the user's data from being served immediately.
3. Phase 2, async cascading deletion: Publish a deletion event and let every downstream service handle its own erasure logic independently.
4. The hard cases: Backups, analytics warehouses, ML training data, and third-party processors each require different deletion strategies.
5. Audit trail and compliance reporting: Prove deletion happened without retaining the deleted data.

The core insight is this: GDPR deletion is a distributed systems coordination problem, not a database operation. You are orchestrating erasure across 10+ services, each with different storage engines, retention policies, and cleanup mechanisms. The pipeline needs to be reliable, auditable, and complete within 30 days.

The Architecture

Here is the full deletion pipeline. The key design decision is the event-driven fan-out: a single UserDeletionRequested event triggers independent cleanup in every downstream service, and a central tracker monitors completion.

Let me walk through this step by step.

The user submits a deletion request through the UI or by emailing the Data Protection Officer (DPO). Before anything happens, identity verification confirms this is actually the account owner, not someone trying to delete another person's data. This typically means re-authentication plus an email confirmation link.

The Core Deletion Service first checks for legal holds. If the user is under active fraud investigation, or there is an ongoing lawsuit involving their data, GDPR provides exceptions. Assuming no hold, the service immediately soft-deletes the user in the primary database: anonymize PII fields, set a deleted_at timestamp, and revoke all active sessions.

Then the service publishes a UserDeletionRequested event to Kafka. Every downstream service consumes this event independently and performs its own cleanup. Each service reports completion back to the Deletion Tracker, which monitors the 30-day deadline and produces compliance reports.

This fan-out pattern is critical. You do not want the core service to know about every downstream system's internal schema. Each service owns its own deletion logic. Adding a new service only requires adding a new consumer, not modifying the orchestrator.

For your interview: name at least five downstream systems (cache, search, analytics, backups, third-party) to show breadth. Most candidates only name two or three.

The Full Deletion Pipeline (All Data Stores)

The first deep dive: what actually needs to be deleted, in what order, and with what strategy. Most candidates name two or three data stores. A strong answer covers the complete topology.

Here is how deletion propagates across every data store in a typical production system.