Why Is Deleting Data Actually So Hard?
Why pressing “Delete” is easy for users but surprisingly complicated for distributed systems.
Deleting a file feels like one of the simplest things a computer can do.
Select it.
Press Delete.
Gone.
But now imagine that instead of a file on your laptop, it's your data stored by a large cloud application.
That data might exist in a database.
And a replica of that database.
And a cache.
And a backup.
And maybe another data center.
Suddenly, “delete my data” isn't one delete operation anymore.
It's a distributed systems problem.
Why Are There So Many Copies in the First Place?
At first, having multiple copies of data sounds unnecessary.
Why not just store everything once?
Because if that one machine fails, your data could disappear with it.
Modern systems therefore use replication. Copies of data can be stored across multiple machines, and sometimes across different physical locations.
This helps systems remain available when hardware fails.
It can also improve performance by allowing users to access data from infrastructure closer to them.
So replication solves an important problem:
How do we make sure data remains available even when things fail?
But it creates another:
How do we make sure data disappears everywhere when someone deletes it?
Imagine Deleting Your Account
Suppose an application stores your profile in its primary database.
You click:
Delete Account
The primary database removes your record.
Done?
Not necessarily.
Maybe another database replica hasn't received that update yet.
Maybe your profile is still sitting inside a cache.
Maybe a search index contains information about your account.
Maybe yesterday's backup contains the old database state.
Now the system has an awkward situation:
Primary database: deleted
Replica: still exists
Cache: still exists
Backup: still exists
Replica: still exists
Cache: still exists
Backup: still exists
From the user's perspective, there was only one button.
Behind that button could be several systems that need to agree that the data is gone.
Caches Make It Even More Interesting
Applications use caches because repeatedly retrieving the same information from a database can be slow or expensive.
Instead, frequently requested information can temporarily live somewhere faster.
That's great for performance.
Until the original information changes.
Imagine your username is cached for 30 minutes.
You update your username in the database.
For a short period, another part of the application might still retrieve the old value from the cache.
Deletion creates the same problem.
Removing the original data doesn't automatically mean every cached copy instantly disappears.
This is one reason cache invalidation has a reputation for being surprisingly difficult.
Then There Are Backups
Backups introduce an even stranger problem.
Their entire purpose is to preserve old data.
If today's database gets corrupted, we might restore yesterday's backup.
That's excellent for reliability.
But suppose someone deleted their account today.
Yesterday's backup was created before the deletion.
So the backup may still contain that person's data.
This doesn't necessarily mean a deleted account suddenly reappears. Real systems can use retention policies, deletion records, lifecycle processes and other mechanisms to handle this.
But it demonstrates an interesting conflict:
Reliability wants us to preserve copies.
while
Deletion wants us to eliminate them.
Both are reasonable requirements.
Designing a system that handles both correctly is the difficult part.
Why Not Delete Everything Immediately?
Because distributed systems don't behave like one giant computer.
Different machines communicate over networks.
Networks introduce latency.
Machines can temporarily become unavailable.
Updates can arrive at different times.
Some systems therefore favor eventual consistency: after an update, every copy may not reflect the change at precisely the same instant, but the replicas are expected to converge toward the same state.
That means deletion may sometimes behave more like:
“This data is now marked for removal across the system.”
rather than:
“Every physical representation of these bytes vanished at exactly 4:32:01 PM.”
Soft Delete vs Hard Delete
There's another interesting design choice.
Sometimes applications don't immediately destroy a database record.
Instead, they might change something like:
deleted = falseto
deleted = trueThe application stops showing the record, but the underlying data still exists temporarily.
That's a soft delete.
It can make recovery easier if something is deleted accidentally.
A hard delete, on the other hand, actually removes the record.
Neither approach is automatically right for every system. The decision depends on things like recovery requirements, retention policies, security and privacy requirements.
The Weird Contradiction of Reliable Systems
The more I thought about this, the more interesting the contradiction became.
We design distributed systems so that:
One failure shouldn't destroy our data.
So we create replicas, caches and backups.
Then someone asks:
Please destroy my data.
And now the exact mechanisms we created to prevent data from disappearing make deletion more complicated.
That's the fascinating part.
One Button, Many Systems
The user sees:
Delete Account
The infrastructure might see:
Update primary database → propagate deletion → invalidate caches → update indexes → handle replicas → respect backup retention → verify completion.
And that's something I find increasingly interesting about cloud and distributed systems.
The simplest actions on the surface can hide some of the hardest engineering underneath.
So the next time your computer asks:
“Are you sure you want to delete this?”
maybe it's not being dramatic after all.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article