Comment by steveBK123
8 months ago
>> 1. When terminating a service, temporarily place it in a state where the service is unavailable but all data is retained and can be restored at the push of a button. Discard the data after a few days. This provides an opportunity for the customer to report the problem.
This is so obviously "enterprise software 101" that it is telling Google is operating in 2024 without it.
Since my new hire grad days, the idea of immediately deleting data that is no longer needed was out of the question.
Soft deletes in databases with a column you mark delete. Move/rename data on disk until super duper sure you need to delete it (and maybe still let the backup remain). Etc..
It sounds like the problem is that the deletion was configured with an internal tool that bypassed all those kinds of protections -- that went straight to the actual delete. Including warnings to the customer, etc.
Which is bizarre. Even internal tools used by reps shouldn't be performing hard deletes.
And then I'd also love to know how the heck a default value to expire in a year ever made it past code review. I think that's the biggest howler of all. How did one person ever think there should be a default like that, and how did someone else see it and say yeah that sounds good?
> This is so obviously "enterprise software 101" that it is telling Google is operating in 2024 without it.
My impression of GCP generally is that they've got some very smart people working on some very impressive advanced features and all the standard boring stuff nobody wants to do is done to the absolute bare minimum required to check the spec sheet. For all its bizarre modern enterprise-ness, I don't think Google ever really grew out of its early academic lab habits.
I know a bunch of way-too-smart PHD types that worked at GOOG exclusively in R&D roles that they bragged to me earnestly was not revenue generating.
It makes sense for companies to have 1-10% of resources allocated for that. At Google scale that is thousands of people.
2 replies →
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.
1 reply →
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.
gdpr compliance precludes such approach