Sounds like a maintenance error and an application design error that led to a flood of traffic. Doesn't sound MongoDB specific.

I don't think there is enough information to come to a conclusion here, but I doubt your proposed failure mode.

Based on my experience with largish data in mongo, my guess would be that the database size was >> than ram and, due at least in part to mongo's design, when the master failed over the memory state of the new master didn't have the working set present in RAM. This lead to a huge inrush of disk IO resulting in all sorts of bad until the RAM state sorted itself out.

My experience with mongo is the same. Works great, in RAM. As soon as you hit disk, it falls over completely.

There’s definitely some truth to parent’s snark:

http://hackingdistributed.com/2013/01/29/mongo-ft/

Really, rolling out the Mongo spite from '13? Isn't there a statute of limitations on this sort of pgres fanboy balderdash?

Haters gonna hate, hate, hate

Even SQLite doesn’t lose data.

This “spite” reveals serious core design flaws in Mongo that still have yet to be addressed.

If someone has data showing otherwise — that the abject reliability and scaling issues were resolved via something like a complete rewrite, I’d be glad to reconsider my views (they won’t have any though).

Honestly I'm a bit surprised they don't use a more mature, fully managed solution. They can't have so much traffic to not justify getting some traditional relational database (like Oracle).