设计网站的共享，重新共享功能，避免重复

Question

This is an interesting interview question that I found somewhere. To elaborate more:

You are expected to design classes and data structures for some website such as facebook or linkedin where your activity can be shared and re-shared. Design should be such that it avoids redundancy and duplication.

While thinking of this problem I was stuck on "link vs copy" problem as discussed here

But since the problem states that duplication should be avoided I decided to go "link" way. This makes sharing/re-sharing easier but deleting very difficult. ie if the original user deletes their post all the shares should be deleted. (programmatically speaking all the objects on the pointing to the particular activity should be made null. And this is the difficult part here, ie to find all the pointing objects)

Answer 1

Wouldn't it be better to keep the shares? The original user deletes their post, fine, it's gone. But everyone who has linked to it should not suddenly have it disappear on them.

This could be done the way Unix handles hard links. "Deleting" just means removing one link to an object -- an inode, in Unix terms. You don't remove the object itself until the link count is zero.

Answer 2

It's not obvious from the original specification that deletion should work as you describe. It might be desired that when the original user deletes the item, it is not deleted elsewhere; in that case you don't necessarily need to track all references, just keep a reference count on each post, and remove it from the database only when the count hits zero.

If you do want the behavior you describe, it may be achievable by simply removing broken links as and when you encounter them, again relieving you of the need to track each reference. The cost of tracking and updating every reference to every post is replaced with the comparable cost of one failed lookup for each referring page. The latter case is simpler to implement, though, and the cost doesn't hit your server all at once.

In real life, I would implement all references as bidirectional anyway, because it's likely to be needed sooner or later as you add features. For example, a "like" counter seems pretty simple, but to prevent duplicate votes you need to keep track of who has liked each item, and then if you want to remove their "like" when they delete their profile, you need to keep a list of each user's outbound "likes" too.

It takes a lot of database activity to implement something like Facebook...