🦥Why Your Delete Button Is a Lie

Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had an amazing week!

Sorry for the lack of emails from me, went on a quick trip, got sick, and then got a bit lazy… but we should be back!

You don't remember that meeting. Nobody does.

I bet right now you couldn't tell me what your last meeting or lecture was about even if your life depended on it.

Don't worry, I can't either. I have the memory of a goldfish. That's why I started using Granola.

It picks up your meetings automatically and transcribes everything in the background while you take notes like normal. No bot joining your call, no “recording in progress” sound, nobody knows it's there.

After the meeting, it takes your messy notes and the full transcript and turns it into a clear summary of the meeting and what you actually need to do next.

You can even share that summary with your team because I bet they forgot too.

Now nobody has to pretend they remember.

Try Granola on your next meeting. Free for a month with code CODINGSLOTH.

Why Your Delete Button Is A Lie

Deleting data sounds like a simple thing to do right?

Click delete. Done.

That's how it feels as a user. One button. Instant. Clean.

But I promise you, 99% of tech companies are NOT deleting your data. Because "delete" is probably the most deceptively complicated word in software engineering.

Problem #1: What does "delete" even mean?

Not a trick question, because you really have to think about it:

When a user deletes something, what are you actually supposed to delete and how?

The naive answer is to remove it from the database.

This can work for new apps with 0 features or for apps that don’t need data, but for a more advanced app, the actual answer:

Which database? The primary? The backups? What about the cache? The analytics pipeline? The audit logs? The third-party integrations you hooked up?

Data doesn't live in one place. It gets copied, cached, replicated, and warehoused the moment it enters your system. "Deleting" something from the main database is like throwing away one copy of a document that's already been photocopied fifty times and filed in ten different cabinets.

The two ways to delete (and why both are painful)

When you need to delete data, you basically have two options:

1. Hard delete

Permanently remove the row from the database. Gone. Forever.

Sounds simple, but this is computer science we’re talking about so It's really not. The moment you hard delete something, you have also ask:

What else depends on this data?

Example scenarios

1. Let’s say a user deletes their account and they’ve been a paying customer for a while. Do you delete all their orders too? What about the invoices attached to those orders? What about past revenue data?

2. Someone posted in your community forum. Dozens of people replied to their threads. Do those replies now float in a void with no parent post? Do you delete those too?

3. Someone referred three friends through your referral program. Those friends got discounts. Do you remove those discounts? Do those accounts get flagged?

4. Someone had an open support ticket when they deleted their account. Your support team was mid-conversation. Does that ticket disappear from your CRM? What does the support rep see?

Real companies have made real decisions about this.

• Reddit decided that when you delete your account, your posts and comments stay up, but they just get attributed to u/[deleted]. They chose broken attribution over broken threads.

• Stripe won't let you delete a finalized invoice at all. You can void it, but voiding still keeps a full paper trail. Once an invoice is paid, that record is permanent. For financial data, hard delete isn't even on the table, it conflicts with tax law and compliance requirements that outrank your delete button.

Hard deletes sound simple and elegant in a database diagram, but they turn into disasters in production because of how tightly coupled everything ends up being.

2. Soft delete

How about we don't actually delete the row. Just add something like an is_deleted = true flag and hide it from queries.

This is what most apps do.

-- Seems fine
UPDATE users SET is_deleted = true WHERE id = 42;

-- And query like this from now on.
SELECT * FROM users WHERE is_deleted = false;

It's safer, it's recoverable, and it feels clean. The problem is it's not actually deletion, it's hiding. 

The data is still there, taking up space, bloating your indexes, and waiting to be accidentally included in a query where someone forgot to filter out deleted records (there are packages that help prevent this mistake…)

Neither option is clean. Every team picks their poison.

Fun fact: @Brandur, a software engineer who worked at Heroku and Stripe created a blog post called “Soft Deletion Probably Isn't Worth It.” He mentioned that in all his time at both companies (10+ years), nobody actually used soft deletion to undelete something.

Problem #2: Your data is everywhere

Let's say you've handled the database. Congrats. You're maybe 20% done.

Because your data doesn't just live in the database. It could live in:

• Caches

• Backups

• Read replica

• Data warehouses

• Microservices

At Twitter (now X), they found that data deletion across a microservices architecture couldn't be treated as an event, it had to be treated as a process. They built an entire "erasure pipeline" dedicated to coordinating deletion across systems and teams.

Think about that. A dedicated pipeline just to handle deletes.

If you're building a monolith today, this isn't your problem yet. But the moment you split into services, add a cache, or hook up an analytics tool, you've created copies you'll eventually have to track down.

This is why as your app gets more complex, deletion is starts to become a distributed systems problem, not a database problem.

Problem #3: GDPR

Now unlike us in America, the EU still cares about privacy.

In 2018, the EU enforced GDPR, which introduced something called the Right to Erasure, also known as the "right to be forgotten." This gave users the legal right to request deletion of all their personal data within one month. Suddenly deleting data became a legal liability with a deadline attached.

Engineers who never thought about deletion now had to prove they could do it.

Two patterns that actually help

1. Soft delete with an async cleanup job. Mark data as deleted immediately so the data disappears from the user's perspective, then run a background job later to actually purge it once you've had time to propagate the deletion everywhere. You get the immediate safety of soft deletion without keeping the dead data.

   2. Encrypt PII (Personally Identifiable Information) at write time, delete the key. Store sensitive personal data encrypted with a per-user key. When someone requests erasure, delete the key. The data still technically exists in your backups but is permanently unreadable. This is called cryptographic erasure, and it's the only realistic solution when backup systems can't be surgically modified. The data is there, but nobody can read it. Ever.

Deleting data is hard because writing data is easy

When you save something, you don't think about where all the copies go. When you delete something, you suddenly have to find every single one of them. You're paying the debt you didn't know you were accumulating.

So next time you're designing a feature that stores user data, ask yourself how you'd delete it before you write a single line.

Thanks to everyone who submitted!

kyanite-web, gcavelier, krunalmtest, sujitha483, Neverever1705, Ishaan282, hamooo21112655, Manzolillom, kaushalsingh01, and yoyowsy!

Vertical Text

Create a function that converts a string into a matrix of characters that can be read vertically. Add spaces when characters are missing.

Examples

vertical_txt("Holy bananas")
output = [
  ["H", "b"],
  ["o", "a"],
  ["l", "n"],
  ["y", "a"],
  [" ", "n"],
  [" ", "a"],
  [" ", "s"]
]

vertical_txt("Hello fellas")
output= [
  ["H", "f"],
  ["e", "e"],
  ["l", "l"],
  ["l", "l"],
  ["o", "a"],
  [" ", "s"]
]

How To Submit Answers

Reply with

• A link to your solution (github, twitter, personal blog, portfolio, replit, etc)

• or if you’re on the web version leave a comment!

• If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.