[surferbayarea]

Facebook's privacy settings have a ton of bugs. Here's another one: 1. Make a stupid status update post. 2. It appears in all your friends newsfeed. 3. You realize you said something stupid and private. 4. Panic. Delete post 5. Breathe sigh of relief that it is no longer showing up in your profile. 6. But wait a minute! It still keeps showing up in all your friends newsfeed. 7. Now that you deleted the post, you can't even modify it's visibility settings. Heck you can't even get to the url. But all your friends continue to see the post in their newsfeeds

So the way facebook implements a delete of any activity(status post/like/comment) is that the owner stops seeing it but everyone else keeps seeing it. That is simply the most retarded delete implementation ever!

[codewright]

Mumble mumble mumble eventual consistency mumble mumble sharded MySQL mumble mumble

[surferbayarea]

This isn't a case of eventual consistency. They don't bother to update the cache(if that is the reason) or update the database used in newsfeed. The deleted posts persist in the newsfeed database many hours(maybe forever) after the delete event.

[codewright]

Caching is a conscious decision to take advantage of eventual consistency.

[nthj]

to be fair,

cache invalidation is hard.

[drivebyacct2]

And naming things.

[Laremere]

Together with off by one errors, they're the two hardest things in computer science...

[alexkus]

Yes, the three hardest things in Comp Sci are cache invalidation and off by one errors.

[marc]

Don't you mean the 10 hardest things?

[jamesrom]

I think he means the 11 hardest things actually.

[mibbitier]

All they need to do is add a new "message" to say "y'know that message number 4029375 in the cache, yeah that ones deleted, ignore it".

This is not hard.

[natrius]

This arrogance is baffling. What makes you think you know enough about Facebook's infrastructure to make such a claim?

[mibbitier]

huh? Infrastructure is totally and utterly irrelevant to the problem. I know enough about common sense to make such a claim.

Just send a new message, exactly as you would post an original item/comment/etc, but have some special text/field in there that says "please ignore the previous message". The UI would then hide the previous message.

eg

  COMMENT: {id:9374758, from:"mibbitier", data:"I hate you all!"}
  COMMENT: {id:9374759, from:"mibbitier", data:"*IGNORE_MESSAGE_IN_UI* 9374758"}

Nothing whatsoever to do with infrastructure. Nothing to do with caches. Purely to do with the UI. Not rocket science.

Granted, it's a poor way to do it, but it's better than nothing, and easier than trying to invalidate caches etc

[nthj]

Here's the thing that customers, managers, and less experienced developers all have in common: they understand that no one thing is difficult. But they don't take into account that managing the complexity between a thousand, or a hundred thousand, or a million rules is very, very difficult.

That's why you hire more experienced developers: they're more experienced, not at things like cache invalidation (sure, just nuke your entire cache anytime anything changes! easy!), but at managing complexity.

Which is difficult.

That's why I try to keep my mouth shut about how somebody should "just do this, it'd be so easy, why are they dumb?"

[mh-]

I'm sure it's already rendered to a static presentation-level (HTML/template language du jour) form at that point. That wouldn't work.

[mibbitier]

Just put some more javascript in there to deal with it. I'm sure it's not the hardest problem in the world.

[pbz]

I suppose they made it work the same as email. Once you sent something you can't take it back, but you can delete your copy if you want.