I remember listening to an interview with Markus from Plenty of Fish, where he essentially said that he didn't worry too much about site errors because most unsophisticated users would attribute them to things like their ISP, browser (if they knew what that was), or their own error more often than to the site itself.

Personally, I can't bring myself to not care like that, but it seems to have worked pretty well in the early days of many now-popular sites. Especially in 2007, when Facebook was still in real competition with MySpace, moving as quickly as possible was probably much more important than a few messages dropping through the cracks.

I must admit my comment was unneccessarily bitter, but my observation is completely different. Many friends and family members are now seeing data loss on Facebook weekly at least. I wouldn't call them tech savvy either, yet they can attribute the issue to Facebook, after having learnt the simplest basics of how the web should actually work.

That's probably by design. Would you prefer one unimportant message lost here and there, or be able to handle 1/1000 of the current traffic to make sure every single message is delivered?

This is exactly the problem. You do not know the message is not important. In fact, every message is important to someone.

In your first comment you implied that it was a problem with PHP. I told you they are doing it on purpose, and not because their code or language is bad, and you now agreed. So I don't know where you are trying to get with this discussion. They have to choose between maximum performance and perfect consistency. They can't have both. So what they are doing is saving money in infrastructure, and letting some messages get lost from time to time. Your family being a little annoyed made them money.

Also, when we say "important" in this context, is almost like asking "are you willing to pay for it?". Most people wouldn't pay a dime for ensuring the consistency of all their Facebook messages. So Facebook chose the right option.

Actually the trade off is not between consistency and performance, but scalability and performance (CAP theorem). Although related, they are not the same concepts.

My opinion is that you can have both performance and consistency, and work your way toward scalability as required. I recall that Facebook has a very high server-per-engineer ratio (though I acknowledge that the user-per-engineer ratio is even higher in comparison to other startups).

I also realize it is not cost-efficient to write bugfree software, but saying they did it the other way on purpose is forgiving them too much. You never write bad software intentionally.

They didn't care, and the world should have relied and should continue to rely on better software.

I know the CAP theorem, but that's not what is going on here. And now again you are saying that the data loss is a bug. It's not! Like I said, it's by design, they are probably using a fire-and-forget methodology for writing the comments. Do you seriously think there is a bug in PHP or their PHP code that is making a very little percentage of comments get lost? Besides, they have moved away from PHP long time ago for their backend. They are using a combination of Java, Scala, etc. Software that loses some data instead of crashing when under heavy load is not bad software. It has its uses, eg: massive amount (per unit of time) of unimportant messages that no one is willing to pay for.