Deleting user data across regions, backups and replicas

A deletion request is only as good as its coverage. Design it as a workflow that fans out to every store in every region, records proof for each, and handles backups by expiry. Be ready to explain honestly how long a copy may remain in a backup.

Start from the map

You need a list of every system that holds the person's data: primary databases, read replicas, caches, search indexes, queues, analytics, logs, backups and vendors. The same inventory used for a transfer map works. Add a deletion method for each row.

A fan out workflow

1. Receive and verify the request. The DSAR process covers verification.
2. Resolve the person to all identifiers: user ID, emails, device IDs.
3. Publish a deletion event with an idempotent request ID.
4. Each region's service deletes or anonymises its data and writes a receipt.
5. Vendors receive deletion API calls or tickets.
6. A coordinator waits for all receipts and records completion.
7. A stuck receipt creates an alert, not silence.

Backups

Deleting one person's records from immutable backups is usually impractical. Common practice is to let backups expire on a fixed retention cycle and to make sure a restore re-applies pending deletions. This needs a tombstone list: record of deleted IDs that any restore job must replay before the system returns to service.

State the retention honestly in your privacy notice and in answers to customers. The topic of limits on erasure is covered in erasure exceptions and limits. For retention design, see how to build a retention schedule.

Cross region pitfalls

• A region that was decommissioned still has a snapshot.
• Analytics copies that were exported to a warehouse in the home region.
• Logs holding emails, kept longer than the primary data.
• Staging databases seeded from production.
• Vendor copies where your contract has no deletion deadline.

Evidence

Keep per request: time received, systems touched, receipts, and exceptions with a reason. Auditors like to sample a few requests end to end.

Test it

Create a test user, populate every system through normal use, delete, then search each store by every identifier. Anything that remains is a bug. Repeat each quarter.

Idempotency and failure

Deletion workflows fail halfway. Make each step safe to repeat, store the request state durably and retry with backoff. A request that has been partly applied must be resumable without deleting the wrong thing. Test with fault injection: kill a regional service during a request and check that the coordinator finishes it later.

Ownership

Every store in the map has a named owner who answers for its deletion method. When a team adds a new store, the pull request template should ask how deletes reach it. Without that question the map falls behind the system.

Quick check

Last reviewed: 19 October 2026.