[gorjusborg]

I think it is a fairly common trait of bad programmers to design a system based on completely unrealistic operating conditions (like multiple orders of magnitude of extra traffic).

Now that they've gotten the hug of death they'll probably plan for it next time.

[grayhatter]

How many ways are their to build a site that doesn't have these defects and risks?

Good engineers build things that eliminate failure modes, rather than just plan for "reasonable traffic". Short of DDoS, a simple blog shouldn't be able to die from reaching a rate limit. But given the site is dead, I can't tell, maybe it's not just a blog.

[gorjusborg]

> Good engineers build things that eliminate failure modes,

Yes, but not all failure modes, only the ones in scope for the goals of the system. From the outside you can't tell what the goals are.

There is no such thing as eliminating all failure modes, which was exactly the point I was making in my post above. The best you can do is define your goal clearly and design a system to meet the constraints defined by that goal. If goals change, you must redesign.

This is the core of engineering.

[grayhatter]

> Yes, but not all failure modes, only the ones in scope for the goals of the system. From the outside you can't tell what the goals are.

Is basic availability not a goal of a blog?

Phrased differently: given two systems, one that fails if a theoretically possible, but otherwise "unpredictable" number requests arrive. And one without that failure mode. Which is better?

> From the outside you can't tell what the goals are.

I either don't agree, not even a tiny bit, or I don't understand. Can you explain this differently?

> This is the core of engineering.

I'd say the core of engineering is making something that works. If you didn't anticipate something that most engineers would say is predictable, and that predictable thing instead of degrading service, completely takes the whole thing down, such that it doesn't work... that's a problem, no?