I'd imagine there's a more innocent reason: deleting things is HARD in systems designed to scale. There are likely to be denormalisations, multiple redundant copies, separate search indexes, caches... bulk deleting an account actually ends up involving a fairly large amount of code.
case in point: i was working for twitter support when Miley Cyrus deleted her account. it took down all of twitter for the better part of a day while the system was trying to invalidate/delete millions and millions of records... that was not fun.
Which is why "at scale" you design systems that let you mark records as deleted (without actually deleting them).
You then need to choose how you explain that to users (preferably before they sign up and start entering sensitive data) as well as the normal problems of deciding the policy about having backups of "deleted" data (if you don't actually delete it - either from the live data set or from archived backups - a court could require you to hand it over).
No its really not. I worked on a system where the average user had hundreds of thousands of objects across dozens of servers.
The delete button sets an account flag saying "this user is deleted." The front end UI honored that and no longer showed the user. A half dozen DELETE tasks were then tossed into a job queue, one for each major subsystem (cache, archival storage, etc). The visual effect of deletion was instant and within 20 minutes everything was gone.
This combined with, THERE IS NO BUSINESS INCENTIVE TO DO SO... is pretty much a reason.
Time is a zero sum game. If I can make features/fixes that brings me money, why would I spend time/money/effort to design system for effectively... well, NOT make money, at the cost of the former?
Comments
I'd imagine there's a more innocent reason: deleting things is HARD in systems designed to scale. There are likely to be denormalisations, multiple redundant copies, separate search indexes, caches... bulk deleting an account actually ends up involving a fairly large amount of code.
case in point: i was working for twitter support when Miley Cyrus deleted her account. it took down all of twitter for the better part of a day while the system was trying to invalidate/delete millions and millions of records... that was not fun.
Which is why "at scale" you design systems that let you mark records as deleted (without actually deleting them).
You then need to choose how you explain that to users (preferably before they sign up and start entering sensitive data) as well as the normal problems of deciding the policy about having backups of "deleted" data (if you don't actually delete it - either from the live data set or from archived backups - a court could require you to hand it over).
No its really not. I worked on a system where the average user had hundreds of thousands of objects across dozens of servers.
The delete button sets an account flag saying "this user is deleted." The front end UI honored that and no longer showed the user. A half dozen DELETE tasks were then tossed into a job queue, one for each major subsystem (cache, archival storage, etc). The visual effect of deletion was instant and within 20 minutes everything was gone.
You just described a (perfectly reasonable) system which would take a nontrivial amount of code to build.
> deleting things is HARD in systems designed to scale.
That's an excuse, not a reason.
This combined with, THERE IS NO BUSINESS INCENTIVE TO DO SO... is pretty much a reason.
Time is a zero sum game. If I can make features/fixes that brings me money, why would I spend time/money/effort to design system for effectively... well, NOT make money, at the cost of the former?
What if you charged to delete an account? (only half joking).