Luckily when a client demands something outrageous they tend to discover that it comes with a formidable price tag. Uptime requires redundancy, redundancy requi

Luckily when a client demands something outrageous they tend to discover that it comes with a formidable price tag. Uptime requires redundancy, redundancy requires a substantial increase in cost without even factoring in the additional development time. A theoretical (as you can't guarantee it anyway) 100% uptime requires a ridiculous amount of redundancy (i.e. consider that you now need to factor in every idiot with a backhoe[1], car[2] or boat[3]). At 100% uptime you have to consider not just your site being up but all the infrastructure between your servers and the given user being up as well. What's better is discussing with your client what happens when they hit downtime and how the negative impact can be mitigated. Can you run a limited service that covers the core functionality of the website (i.e. only make the core components redundant[4])? What parts of the service are absolutely desired? How much money will the client lose (either directly or through lost customer faith)? You'll tend to find the client will realise the time is better spent developing features or improving the user experience than worrying over that last 0.1% between 99.9 and 100. [1]: http://www.wired.com/science/discoveries/news/2006/01/70040 http://www.wired.com/science/discoveries/news/2006/01/70040 [2]: http://www.datacenterknowledge.com/archives/2010/05/13/car-crash-triggers-amazon-power-outage/ http://www.datacenterknowledge.com/archives/2010/05/13/car-c... [3]: http://en.wikipedia.org/wiki/2008_submarine_cable_disruption http://en.wikipedia.org/wiki/2008_submarine_cable_disruption [3]: http://techblog.netflix.com/2011/07/netflix-simian-army.html http://techblog.netflix.com/2011/07/netflix-simian-army.html