[devishard]

> It's a completely reasonable tradeoff as long as you can quantify the risk and quantify the cost (here's a tip for something that scarily few engineering organizations does: track not just time spent on projects, but calculate the cost per feature and report on it; it very quickly changes organisational priorities when managers see that what they thought was a minor change ended up costing $10k engineering time)

Except it's not a tradeoff: you don't get anything for it that you couldn't get from another data store option. Maybe MongoDB was the only option for some things 5 years ago, but it's not now. There are other options that don't leak memory and lose data.

> Do you think we just randomly say "oh, lets just lose data for fun?"

Basically, yes. You're claiming you weighed the benefits agains the tradeoffs, but I'm saying that you can get all those benefits without making a tradeoff.

>As above: Serves crash. So if your system needs to be available, you need according redundancy. The typical additional scaling cost (accounting for a slightly increased risk of simultaneous restarts, requiring a small amount of extra capacity) of dealing with restarts on resource constraints are often perfectly ok. I tend to design all systems I work on to allow as many components at possible to be restarted at will, because you need to be able to accommodate upgrades etc. anyway. If you first do that, then allowing automatic restarts in the case of failure-types where that is acceptable tends to be trivial.

Of course you should build redundancy into the system, but that's to handle unforseen problems, not to handle problems which you know are there from the start.