Right to erasure / right to be forgotten
A user's right to make you actually delete their data wherever it lives, not just flip a flag, minus whatever you can prove you must keep.
See it
What it is
GDPR Article 17. A person can make you delete their data when you no longer need it for the purpose you collected it, when they withdraw the consent you were relying on and you have no other basis, when they successfully object, or when you processed it unlawfully. The catchier name, 'right to be forgotten', comes from the 2014 Google Spain ruling and strictly speaking covers a narrower thing: getting search engines to delist results about you.
In practice this is a fan-out problem, not a legal one. One person exists in your primary database, a read replica, last night's backup, the warehouse, Stripe, the support inbox, the email platform, the analytics tool, Sentry breadcrumbs, and a spreadsheet someone exported in March. Erasure means a deletion job that reaches all of it, plus a written position on backups: the accepted approach is to put backup copies beyond use, exclude the person from restores, and let normal rotation age them out, as long as you can say that clearly.
Two gotchas. First, soft delete is not erasure. If a support agent can still read the row, nothing was deleted. Where you need referential integrity or revenue history to survive, replace the person with a tombstone: keep the internal ID and the order totals, destroy every field that points at a human. Be honest about what that leaves behind, though. A retained internal ID or a hashed email is normally still pseudonymous personal data, not erased data, so the surviving row has to sit under a documented exception or be genuinely impossible to tie back to the person. Second, erasure is not absolute. You may and often must keep records you are legally required to hold, such as tax invoices, so the correct answer is usually 'deleted everything except X, here is why', delivered in writing inside the deadline.
Ask AI for it
Implement a real erasure path for this app, triggered by a single eraseUser(userId) job. Walk the schema and produce a deletion plan per table: hard delete, anonymize in place, or retain with a documented legal reason. For records that must survive for accounting or referential integrity (orders, invoices, ledger entries), replace personal fields with a tombstone: keep the internal ID and amounts, and delete or irreversibly anonymize name, email, address, phone, and IP. Do not treat ordinary hashing as erasure, because a hash is still a pseudonym anyone holding the same input can reproduce. Retain only fields covered by a documented legal exception, and verify that whatever combination survives cannot reasonably re-identify the person. Extend the job to everything outside the database: object storage uploads, the analytics and error-tracking vendors, the CRM and email platform (deletion API plus suppression list so they are not re-imported), search indexes, caches, and any denormalized copies. Make it idempotent and resumable, log every target with a result, and emit a machine-readable erasure receipt. Add a backup policy note stating that backups are put beyond use and the user is excluded from restores. Write tests that seed a user into every system and assert nothing identifiable remains afterwards.