We're running MongoDB in an extremely write heavy environment (web crawling). Another solution for the write issues is to split out a single write connection from all of the other read connections and MongoDB gives the reads execution priority before the writes (in principal, in practice and in my experience it's pretty close).
Again this debate comes down to how you structure your data and picking the best model for that and then figuring out how/if you can deal with its idiosyncracies. The single server redundancy issue has been beaten to death and for any production application should be planned in from the beginning regardless of the database.
Interesting, I didn't know that priority was given to reads(in theory anyways). Thanks for the tip!
As for server durability, yes, it has been beaten to death. Yet, I still talk to developers that either have no idea that's how Mongo operates, or don't know what save mode has to offer.
Again this debate comes down to how you structure your data and picking the best model for that and then figuring out how/if you can deal with its idiosyncracies. The single server redundancy issue has been beaten to death and for any production application should be planned in from the beginning regardless of the database.