Strategy: Saving Your Butt With Deferred Deletes
Deferred Deletes is a technique where deleted items are marked as deleted but not garbage collected until some days or preferably weeks later. James Hamilton talks describes this strategy in his classic On Designing and Deploying Internet-Scale Services:
Never delete anything. Just mark it deleted. When new data comes in, record the requests on the way. Keep a rolling two week (or more) history of all changes to help recover from software or administrative errors. If someone makes a mistake and forgets the where clause on a delete statement (it has happened before and it will again), all logical copies of the data are deleted. Neither RAID nor mirroring can protect against this form of error. The ability to recover the data can make the difference between a highly embarrassing issue or a minor, barely noticeable glitch. For those systems already doing off-line backups, this additional record of data coming into the service only needs to be since the last backup. But, being cautious, we recommend going farther back anyway.
Mistakes happen and James says in Stonebraker on CAP Theorem and Databases that:
Deferred delete is not full protection but it has saves my butt more than once and I’m a believer. If you have an application error, administrative error, or database implementation bug that losses data, then it is simply gone unless you have an offline copy. This, by the way, is why I’m a big fan of deferred delete.
Something to consider in your own design.
