|
|
|
|
|
by sgrenfro
4741 days ago
|
|
When the delete button affects a single row in a single database table, it's indeed really simple. Even if it's a few rows on a single database, you can use transactions. Either way, the deletion succeeds or you surface an error message. But for a large social site, it starts to become a more interesting distributed systems problem. Even for a simple story with 4 likes, 12 comments, and likes on several of the comments, the data is sharded across several databases. Simple transactions no longer work. One option is looking for scalable distributed transactions. A more likely option is making sure deletions can be interrupted and restarted without losing state. Now imagine a public figure whose post has tens of thousands of comments and hundreds of thousands likes. You may not be able to load all of those rows in a single request let alone delete them synchronously. Instead, you have to be able to process the deletion incrementally, reading and deleting some of the data then later picking up where you left off the last time you were interrupted. Interestingly, the order of these operations can also be important. If you're interrupted between deleting a comment and deleting the likes on that comment, will you still be able to find the likes when you restart? We've put a lot of work into a deletion framework that deals with these and many other issues. We're hoping to share more details about it in the future. |
|