>Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible I agree with the top comments on StackExch

>Rather than explaining how it could be done, the answers merely say why you shouldn't do it or why it is impossible I agree with the top comments on StackExchange. It's our job as technical experts to explain to technical non-experts when their expectations are out of line with reality. Anyone who has planned out a redundant system has heard from every single one of their clients that they want "100% uptime". The problem is that 100% uptime has an explicit definition and it's important to point out that it's not practical as a goal. How much better is it to state, "I know you said 100% uptime, but let's explore what's practical and plan for the down time you will have." This part is extremely curious itself from the original request: >In a nutshell, the application will live on servers within the client's network. All but the largest of clients have no idea how to run a data center that can approach even 99.999% availability. It requires redundant servers, redundant storage, redundant LAN connections, redundant WAN connections, redundant firewalls, robust security, on-site staff operators 24x7, battery backed up power, diesel generator backed up power, a massive storage tank for diesel fuel, a disaster recovery site, plans for phased patching, plans for data synchronization, etc, etc. To get anywhere near to 5 nines is millions of dollars. There are very few clients that are willing to spent a fraction of that. Why not tell them the truth that they're going to have a couple days of downtime per year and that they should plan for it?