Hacker News Reader

I've come round to the "fail hard and early" view, provided you can be sure in your design that it doesn't leave junk lying around. Because otherwise contaminated data and invalid states start propagating everywhere..

View on HN

This can be fun if it's a particular client request that causes a hard failure, and the client retries several times before giving up. Before you know it, all your instances are restarting and no traffic is being handled...

So fail early, but not too hard.

Interestingly I prefer failing hard specifically for data consistency reasons. I've had to deal with systems that swallowed far too many errors and let themselves get into an inconsistent state which then caused other operations to not fail but instead persist invalid data. It's very hard to clean messes like that up (restoring a nightly backup is easy, but that's a last resort).

Reply on news.ycombinator.com