← Back to context

Comment by nikanj

8 months ago

There are many voices in the industry arguing against soft deletes. Mostly coming from a very Chesterton's Fence perspective.

For some examples https://www.metabase.com/learn/analytics/data-model-mistakes...

https://www.cultured.systems/2024/04/24/Soft-delete/

https://brandur.org/soft-deletion

Many more can easily be found.

For the use case we're discussing here, of terminating an entire service, the soft delete would typically be needed only at some high level, such as on the access list for the service. The impact on performance, etc. should be minimal.

  • Precisely, before you delete a customer account, you disable its access to the system. This is a scream test.

    Once you've gone through some time and due diligence you can contemplate actually deleting the customer data and account.

    • I think the reason why someone wouldn't want to do this is because it will cost Google money to keep it active on any level.

OK, but those examples you gave all boil down to the following:

1. you might accidentally access soft-deleted data and/or the data model is more complicated 2. data protection 3. you'll never need it

to which I say

1. you'll make all kinds of mistakes if you don't understand the data model, and, it's really not that hard to tuck those details away inside data access code/SPs/etc that the rest of your app doesn't need to care about

2. you can still delete the data later on, and indeed that may be preferable as deleting under load can cause performance (e.g. locking) issues

3. at least one of those links says they never used it, then gives an example of when soft-deleted data was used to help recover an account (albeit by creating a new record as a copy, but only because they'd never tried an undelete before and where worried about breaking something; sensible but not exactly making the point they wanted to make)

So I'm gonna say I don't get it; sure it's not a panacea, yes there are alternatives, but in my opinion neither is it an anti-pattern. It's just one of dozens of trade-offs made when designing a system.