In a distributed system, DELETE is not a command. It's a request.

And most of the systems you're asking don't have to say yes.

When you write data in a distributed system, the architecture works for you.

Replication copies it to three nodes before you get an ack. The CDN caches it at 40 edge locations so it loads fast. The event stream fans it out to every downstream service that subscribed. The read replicas pick it up within milliseconds. The analytics pipeline exports it to the data warehouse overnight.

You built all of this intentionally. Fast. Durable. Available. The data travels far and it travels fast — that’s the point.

Now delete it.

The database DELETE executes in microseconds. The row is gone. Your audit log says deleted. You move on.

Except the three replication nodes each have a copy. The CDN edge caches have it. The event stream already emitted it — and every downstream service that consumed that event has already processed it and written it to their own storage. The read replicas haven’t caught up yet and are still serving the deleted record to live traffic. The analytics warehouse has it in last night’s export. The mobile client fetched it this morning and cached it locally. The partner API you sync to pulled it two hours ago.

The DELETE was a local operation. The data had already become a distributed fact.

Here’s what nobody states plainly:

Every mechanism you built for availability works against you when you delete.

Replication — designed to survive node failures — now means your deleted data survives the delete. Caching — designed to reduce latency — now means stale data outlives its source. Event streaming — designed to decouple services — now means downstream systems received the data before your delete even ran, and they never receive the retraction.

The architecture that makes your system resilient makes your deletes leaky.

This is why “just delete it from the database” is a sentence that only makes sense in a single-node world. In a distributed system it doesn’t even describe a coherent operation. You’re not deleting. You’re marking one node as authoritative and hoping everything else converges — on a timeline you don’t control, through pipelines you may not own, to systems that may not support retraction at all.

GDPR’s right to be forgotten isn’t a legal challenge dressed up as a technical one. It’s a distributed systems problem dressed up as a legal one.

It asks you to achieve global consistency on a delete — across every system your data touched, including systems you don’t operate, including caches with TTLs you didn’t set, including partner pipelines you can’t reach — with a hard deadline and legal liability if you miss a copy.

That’s not an unusual requirement. It’s just an unusually honest description of what deletion has always required in a distributed system, and what most teams have been quietly not doing.

The system you designed to never lose data is also the system that will never quite delete it.

Both are the same property. You just only call it a feature in one direction.

Fault Lines — byte-size system design, one concept at a time.