Deletion requests get treated as a legal obligation with a technical footnote. It is the other way round. Writing 'we will delete your data on request' takes an afternoon; making it true across a production database, thirty days of backups, an analytics warehouse, a search index, a CDN and eleven processors is an architecture problem that most systems were never designed for.
01You cannot delete what you have not mapped
The first honest step is an inventory: every place personal data lands, including the ones nobody planned. Application database, replicas, backups, warehouse, search index, cache, logs, error tracking, email provider, CRM, support desk, analytics, and whatever a spreadsheet exported to someone's laptop three quarters ago.
That inventory is uncomfortable to produce and it is the entire foundation. Teams that skip it build a deletion routine covering the main database, declare the problem solved, and discover during an audit that customer emails were sitting in error-tracking payloads the whole time.
| Location | Commonly missed | Deletion difficulty |
|---|---|---|
| Primary database | No | Easy |
| Read replicas | Sometimes | Easy, propagates |
| Backups | Rarely handled | Hard - see below |
| Analytics warehouse | Very often | Moderate, needs a join key |
| Search index | Often | Easy if you remember |
| Logs and error tracking | Almost always | Hard, often unstructured |
| Third-party processors | Often | Depends entirely on the vendor |
02Backups: the honest answer
You cannot selectively delete one person's record from an immutable backup without restoring, modifying and re-taking it, which is impractical at any real cadence. Regulators broadly accept this, provided your approach is documented and defensible.
The workable position is: deletion is applied to live systems immediately, backups age out on a defined retention schedule, and any restore from an old backup re-applies pending deletions before the data becomes live again. That last part is the bit teams forget, and it is what makes the position defensible rather than merely convenient.
03Soft delete is not deletion
Setting deleted_at and filtering it out of queries is a useful product pattern and it does not satisfy an erasure request. The data is still there, still in backups, still readable by anyone with database access, and still exportable by any query that forgets the filter.
Real erasure means the personal fields are gone or irreversibly anonymised. Frequently you need to keep the row - an order still has to exist for financial reporting - so you null the identifying fields and keep a pseudonymous key. That is a legitimate approach, and it needs to be designed rather than discovered mid-request.
| Data | Approach | Why |
|---|---|---|
| Account profile | Hard delete | No retention basis once account closed |
| Order history | Anonymise, keep record | Statutory financial retention |
| Support conversations | Delete or redact | Often contains data about third parties |
| Analytics events | Delete by user key | Requires the key to be stored |
| Application logs | Age out, avoid writing PII | Prevention beats deletion |
04Processors are your responsibility, not your excuse
Every third party holding data on your behalf must delete when you do. Some have an API for it, some have a support form, some have nothing and require an email that gets answered eventually. Under both GDPR and India's DPDP framework this is your obligation regardless of how cooperative the vendor is.
Maintain a processor register with the deletion mechanism and expected turnaround for each, and automate what can be automated. Then verify - sample a deleted user against each processor periodically, because vendors change their APIs and the failure is silent.
05Design for it now or retrofit it painfully
Systems that handle deletion well share a few properties: a single user identifier that propagates everywhere so deletion can follow it, personal data concentrated in known tables rather than scattered, no PII in logs by default, and retention policies enforced by scheduled jobs rather than intention.
Retrofitting those into a mature system is expensive, and it is the reason deletion requests are often handled manually by an engineer running ad hoc queries. That works at ten requests a month and fails completely at a thousand, which is where you end up after any consumer-facing growth.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer