← Home
💬Real-life Scenario-based Interview QuestionsInterview QuestionsNEW
Advanced
Experience levelSenior · 5+ YOESenior / staff depth expected

A user requests account deletion under GDPR. User data lives in many microservices, warehouses, and backups. How do you delete or anonymize personal data across services without leaving orphans or breaking referential integrity?

GDPRPrivacyMicroservicesData Lifecycle

How I frame it

Right to erasure is a distributed workflow with proof, not a single DELETE FROM users. Clarify legal basis (some data must be retained — invoices), then design an orchestrated erase that is idempotent, auditable, and handles async stores (logs, ES, backups).

Core design

  • Canonical user id everywhere; deletion ticket erasure_requests(id, user_id, status, requested_at).
  • Orchestrator / saga: Publish UserErasureRequested. Each service owns a checklist handler: delete/anonymize its tables, then ack ErasureCompleted(service=…).
  • Retain vs erase: Legal hold / tax invoices → anonymize PII fields, keep financial row with opaque user_hash. Profiles, tokens, device ids → hard delete.
  • Derived systems: ES, Redis, CRM, email tools — consumers of same event or CDC tombstones.
  • Completion: Erasure marked DONE only when all required services ack (or timed out into MANUAL with SLA breach alert).
UserErasureRequested(u123)
  Auth: wipe sessions, bump token_version
  Profile: DELETE PII
  Orders: anonymize name/address; keep order amounts
  Search: delete user docs
  Warehouse: suppress user in next ETL; note backup lag policy
  Audit: append-only proof of erasure steps

Backups & logs

  • Backups: document retention; erasure fulfilled on live systems + ensure restores re-apply erasure list (erasure tombstone table). Pure immediate purge of all cold backups is often impractical — legal counsel defines acceptable residual risk window.
  • Logs: avoid writing raw PII; if present, TTL + scrub pipelines; drop user_id from unrestricted log stores over time.

Weak answer

"Delete from the users table; FKs cascade someday." Leaves PII in notifications, support tickets, analytics. "Drop the database backup." Not a complete or safe answer alone.

Follow-up questions

User signs up again with same email?

New user_id; old anonymized rows stay detached. Email may be reusable after purge — product / fraud policy.

Service never acks?

SLA timers → page owning team; erasure stays OPEN; do not lie to the user that deletion is complete.

How do you prove compliance?

Immutable audit of steps + timestamps + operator; periodic re-scan for PII patterns on known stores.