I don't like 'no single point of failure' maxim because I think it leads people to make strange or incorrect decisions and neglect things in order to serve the maxim instead of doing what's best.
Being 'fail safe' is much more important than being redundant. That is, you need to design your product's failure. How well it works and how rarely it fails are important, but not nearly as important as how well it fails.
This means monitoring for knowing when it fails, auditing for knowing how it did fail after the fact, backups for after the fact, and most importantly (and harder to define) is predicting what can fail and how and designing your product's behavior after that failure.
I agree that monitoring and quick recover are important. It is hard to eliminate all points of failure.
My favorite failures are what I call "distributed single points of failure". An example is a linux bug that is triggered by a cron-job that is set to run at the same time across all servers.
Comments
I don't like 'no single point of failure' maxim because I think it leads people to make strange or incorrect decisions and neglect things in order to serve the maxim instead of doing what's best.
Being 'fail safe' is much more important than being redundant. That is, you need to design your product's failure. How well it works and how rarely it fails are important, but not nearly as important as how well it fails.
This means monitoring for knowing when it fails, auditing for knowing how it did fail after the fact, backups for after the fact, and most importantly (and harder to define) is predicting what can fail and how and designing your product's behavior after that failure.
I agree that monitoring and quick recover are important. It is hard to eliminate all points of failure.
My favorite failures are what I call "distributed single points of failure". An example is a linux bug that is triggered by a cron-job that is set to run at the same time across all servers.