Compliance & Data Governance
'Delete this user's data' sounds simple — until you count every system, backup, and cache that ever touched it.
Overview
Regulations like GDPR, CCPA, and HIPAA impose real, legally-binding obligations on how personal data is stored, and the Right to Be Forgotten in particular — completely deleting a user's data on request — turns out to be one of the hardest engineering problems this entire journey has covered, precisely because of how many systems now touch that data.
Why It Exists
By the time a system has a primary database, a cache (per Cache Invalidation Patterns), a search index, a data warehouse, a Vector DatabaseA database (pgvector, Qdrant, Pinecone) built to store high-dimensional embeddings and run similarity search over them.Learn more (per the previous chapter), and years of backups (covered next), a single user's data can exist in a dozen different places, in a dozen different formats. Compliance and data governance exist as an engineering discipline because deleting data "everywhere it might be" turns out to be structurally much harder than storing it everywhere in the first place — every system that copies data forward needs an explicit, tested deletion path, or the Right to Be Forgotten simply cannot be honestly fulfilled.
Real World Example
A user exercises their GDPR right to erasure. Deleting their row from the primary Postgres database is the easy part. The same user's data also lives in: a Redis cache (until its TTL expires), an Elasticsearch index (until a re-index job runs), a vector database storing embeddings of their support tickets (until an explicit deletion job targets them), a data warehouse's nightly ETL snapshots, and up to a year of point-in-time database backups. A genuinely complete deletion has to reach every one of these, on a defined timeline — not just the primary database.
Example Data
Where 'delete this user' actually has to reach
| System | Deletion Mechanism | Typical Delay |
|---|---|---|
| Primary database | DELETE statement | Immediate |
| Cache (Redis) | Explicit key eviction, or wait for TTL | Immediate to hours |
| Search index | Re-index or explicit document delete | Minutes to a full re-index cycle |
| Backups | Excluded on next backup cycle, or a compliant retention/purge policy | Up to the full backup retention window |
The Regulations, and What They Actually Require
GDPR — the EU's Data-Protection Law
Includes the Right to Be Forgotten among broader requirements around consent, data minimization, and breach notification — the strictest and most widely-referenced of the three regulations.
CCPA — California's State-Level Equivalent
Grants California residents rights to know what personal data is collected and to request its deletion, with somewhat different scope and enforcement mechanisms than GDPR.
HIPAA — US Healthcare Data Protection
Governs how protected health information specifically must be stored, accessed, and audited — a different regulatory focus (access control and audit trails) than GDPR/CCPA's deletion-rights emphasis.
Right to Be Forgotten — the Hard Engineering Problem
Requires tracing every system a piece of user data was ever copied into — including caches, indexes, warehouses, and backups — and having a real, tested mechanism to delete it from each one within a defined timeline.
Diagram
One user's data, copied forward into every downstream system that ever read it
Primary database
Cache
Search index
Vector DB
Backups
A real deletion request must reach every one of these
Common Mistakes
Treating 'delete the user's row from the primary database' as fulfilling a Right to Be Forgotten request
Why: Any copy of that data in a cache, search index, warehouse, or backup remains recoverable or servable even after the primary row is gone — a partial deletion doesn't meet the regulation's actual requirement.
Fix: Maintain an explicit map of every system a given category of personal data flows into, and build a tested deletion path reaching all of them.
Assuming backups are exempt from deletion requirements because they're 'just for disaster recovery'
Why: Most interpretations of GDPR/CCPA still require personal data to eventually be purged from backups too, typically by excluding deleted users from future backups and bounding how long old backups (which may still contain them) are retained.
Fix: Design backup retention policies with a defined maximum age, so that even data present in an old backup ages out of existence rather than being retained indefinitely.
Building compliance as an afterthought, bolted onto a system that already has data scattered across many stores with no tracking
Why: Retrofitting a reliable deletion path across systems that were never designed with data lineage in mind is far more expensive and error-prone than designing for it from the start.
Fix: Track data lineage (which systems a given piece of personal data flows into) as new features and integrations are built, not only when a deletion request forces the question.
Interview Questions
What does the Right to Be Forgotten actually require, beyond deleting a row from the main database?
It requires that a user's personal data be deleted from every system it was ever copied into — caches, search indexes, data warehouses, and eventually backups — not just the primary database where it was originally stored.
Why are backups a particularly hard part of fulfilling a data deletion request?
A backup is a frozen snapshot of the database at a point in time — you generally can't selectively delete one user's data from an existing backup file without restoring, editing, and re-creating it. The practical approach is instead to exclude the user from future backups and bound backup retention so that old backups containing them eventually expire and get purged.
How would you design a system's data architecture from the start to make Right to Be Forgotten requests tractable, rather than a scramble each time one arrives?
Track data lineage explicitly — maintain a registry of every downstream system (caches, indexes, warehouses, vector stores, analytics pipelines) that a given category of personal data flows into, updated whenever a new integration is built. Build and test an automated deletion pipeline that fans a deletion request out to every registered system, rather than relying on someone manually remembering every place data might have ended up. Bound backup retention explicitly so that even data that can't be selectively purged from a snapshot ages out on a known timeline. This turns compliance from an ad hoc audit into a designed, testable capability of the system.
Production Best Practices
Do
✓Track data lineage — which systems each category of personal data flows into — as an ongoing practice.
✓Build and test an automated deletion pipeline that reaches every downstream system.
✓Bound backup retention so old backups eventually purge data that couldn't be selectively deleted.
Don't
✗Don't treat deleting from the primary database as fulfilling a deletion request on its own.
✗Don't assume backups are exempt from deletion requirements.
✗Don't leave compliance as an afterthought bolted on only when a request forces the question.
Comparison
| Primary Focus | Deletion Rights? | Jurisdiction | |
|---|---|---|---|
| GDPR | Consent, data minimization, deletion | Yes — Right to Be Forgotten | EU |
| CCPA | Disclosure and deletion rights | Yes — right to delete | California, US |
| HIPAA | Access control, audit trails | Not primarily deletion-focused | US healthcare |