Right to Erasure at Scale: Why We Replaced Hard Delete with Queues

GDPR gives every user the right to have their data erased. On the backend, that right has a concrete name: account deletion. It is one of the most underestimated projects I know.

TL;DR: at 10,000 users, deleting an account is a SQL statement. At 25 million, it is a distributed workflow. On the healthcare platform I work on, we migrated hard delete to deletion queues. Idempotent steps, replayable, logged. Here is why, and how to build the same thing.

This article is for backend developers who have to take GDPR Article 17 seriously. So, sooner or later, almost everyone.

The setup

I work on an authentication platform for healthcare. More than 25 million users, more than 1,000 sites, several regions.

With health data, the right to erasure is not a thought experiment. Requests come in every week, and each one has a legal deadline.

At the start, deletion relied on direct hard delete. A hard delete erases the data for good, immediately. The API received the request, and the database ran the DELETEs on the spot.

We ended up migrating all of it to distributed queues. A queue is a list of jobs that another program processes later, at its own pace. This was not an architect's whim. Here is what breaks.

What breaks first: the giant transaction

An old account touches dozens of tables. Profile, preferences, consents, history, links to applications.

A cascading DELETE turns all of that into one huge transaction. Locks pile up. Replication falls behind. Other queries wait.

Meanwhile, the HTTP request has a timeout. It gives up after 30 seconds. The transaction keeps going, or rolls back, with nobody left to read the answer.

The user clicks again. A second giant transaction starts on the same rows. Good luck.

A synchronous DELETE works fine in dev. It still works at 10,000 accounts. Then one day it does not.

The real problem: no transaction covers everything

The worst part is not the size of the transaction. The worst part is that a user's data no longer lives in one database.

Run the inventory on your own system. The main database. The Redis cache. The search index. File storage. Logs. Analytics. Third-party processors.

No SQL transaction covers that set. Deleting means coordinating several systems, and each one can fail.

The regulator reached the same conclusion. The EDPB, the European Data Protection Board, audited the right to erasure across Europe in 2025. Its February 2026 report points at weak internal procedures and systems unable to erase everywhere.

Users push too. In the Netherlands, erasure complaints were 18.6% of everything the authority received in 2024. The largest single category.

The design that holds: a queue and idempotent steps

The deletion request becomes a record, not a long-running query. The API answers in milliseconds: request accepted.

The account is deactivated immediately. Sessions revoked, login refused. From the user's point of view, the account is gone.

Then an orchestrator runs the purge, step by step. One step per data domain.

# The purge, one step per data domain
steps := []DeletionStep{
    revokeSessions,    // tokens and sessions
    deleteProfile,     // main database
    purgeSearchIndex,  // search index
    deleteFiles,       // object storage
    notifyProcessors,  // third-party processors
    writeErasureProof, // proof journal
}

Every step is idempotent. Idempotent means: replaying the step gives the same result. Deleting an already deleted row does nothing. That is what makes retries safe.

Every step has its retries and its dead-letter. The dead-letter is the queue of jobs you failed to process. It must trigger an alert, not sleep in a corner.

In our case, the orchestration runs on distributed queues and a workflow engine, with Temporal and Azure Service Bus. The bricks matter less than the three rules: split, idempotent, logged.

Deactivate now, erase for good later

GDPR Article 12 gives you a month to handle the request. You do not need to erase everything within a second. You need to erase for good.

Watch out for the opposite trap. A soft delete is not erasure. Setting a deleted_at on a row deletes nothing.

The EDPB flags exactly that drift: flags or homemade anonymization presented as erasure. Reversible anonymization is just data with a sticky note on it.

The sequence that works has three phases. Immediate deactivation. A short cancellation window, if your product justifies one. Then the final purge, system by system.

Backups, the blind spot

Backups keep full copies of your database. You cannot open them one by one to remove a single user.

The EDPB lists backups among the most frequent technical limits. The topic deserves a written rule, not an embarrassed silence.

My position: short, documented retention. Backups expire, and erasure becomes complete at expiry. Plus a written restore procedure: replay the deletion journal after any restore.

Netflix documented the same project at its own scale: a centralized deletion platform, 76.8 billion rows erased across 1,300 datasets. Nobody outgrows this problem.

Prove that you erased

A supervisory authority will not ask for your good faith. It will ask for evidence.

So every step writes a journal line: which data category, which system, when. Never the content. An erasure journal that contains personal data would defeat its own purpose.

The request has a terminal state: erased everywhere, with a date. A metric tracks requests in flight. An alert fires when a request exceeds its time budget.

When the audit comes, you answer with a journal. Not with a promise.

The checklist before your next erasure request

Run this list against your current system. Every unchecked box is a future incident.

• [ ] Map where a user's data lives: databases, caches, indexes, files, logs, processors
• [ ] Turn the request into a record: immediate response, account deactivated on the spot
• [ ] Split the purge into idempotent steps, one per data domain
• [ ] Give every step retries and a dead-letter that alerts
• [ ] Journal every erasure by category, never by content
• [ ] Write down backup retention and the replay-after-restore rule
• [ ] Test the full deletion journey in staging, regularly

What to remember

A DELETE is not an erasure system. At scale, erasure is a workflow: queues, idempotent steps, a journal that proves it.

The topic is leaving the blind spot. European authorities ran their first coordinated action on the right to erasure, and complaints keep climbing.

The right time to build this is before the request that gets stuck.

Need to industrialize the right to erasure on your backend? Let's talk.

---

Sources: EDPB, launch of the coordinated enforcement on the right to erasure (March 2025) · EDPB, coordinated action findings (February 2026) · InfoQ, Netflix's deletion platform (November 2025) · GDPR, Articles 12 and 17 (EUR-Lex)