03.04 · Concept
Privacy, Data Export & Deletion
Enumerate everywhere one user's data lives - primary tables, derived tables, caches, logs, analytics, backups - and say which of those a deletion request can and cannot reach.
User deletion is a system-wide data lifecycle problem, not a users-table operation. Personal data can appear in serving stores, derived datasets, files, queues, indexes, logs, analytics tools, support systems, processors, caches and backups. A credible design maps those locations and separates immediate deletion from anonymisation, async cleanup, retention and access control.
What this lesson answers
- where can one user's data live
- how to handle user deletion across systems
- what data cannot be deleted immediately
Notes
A privacy export or deletion request is not just a query against the users table. A single user's data can live in primary application tables, uploaded files, search indexes, message queues, recommendation features, billing systems, customer support tools, analytics warehouses, monitoring logs, fraud systems, caches, and backups. The first engineering task is to build a data map: every place where user identifiers, content, events, or derived facts about that user may exist.
Think of user data as a graph, not a row. The account record is only the root.
Common questions
- Why is deleting a user account not enough?
- The account row is only one copy of a user's data. Production systems copy, transform and export user information into indexes, logs, warehouses, support tools, billing systems, queues and backups. Deleting the primary record may remove login access, but it does not remove derived facts, operational traces or third-party copies.
- What should a user data map include?
- It should list every system that may hold identifiers, content, events or derived facts for a user. That includes primary application tables, object storage, caches, search indexes, analytics, monitoring logs, fraud systems, customer support tools, billing, message queues, processors and backup media. Each entry needs an owner and deletion behaviour.
- Can backups and immutable logs be deleted on request?
- Usually not directly. Backups and append-only logs often exist for recovery, audit or security reasons and may be impractical or unsafe to rewrite. They are normally handled through expiry, restricted access and restore procedures that prevent deleted data from returning to live systems.
Short definition: what is Privacy, Data Export & Deletion?