When something crops up a few times I feel like making a post. It is important to remember that when evaluating an architecture, especially on its "availability" credentials it is important to consider the service and everything within its boundary: all its layers, subsystems, dependencies and so forth.
An architecture that comprises one component with shared nothing (e.g. a web server with static content) can be made very highly available very cost effectively through scale out redundancy. This is a very wide and very shallow architecture. The same unit of deployment can be replicated around the globe on different networks etc.
An architecture that is very narrow and very deep is likely to struggle to meet the same degree of availability. If the web server depends on a database and other web services with a series of dependencies beneath it then it becomes very hard. With the web servers dependent on the database there is a single point of failure that could defeat the scale out redundancy of the web tier, so you employ database clustering, but how do you distribute the database for geo-clustering... The cost goes up.
Despite the cost issue, to purely evaluate the availability of the narrow and deep architecture you need to consider each component. If the web service tier is built and operated to 99.9% availability, and the database to 99.9% and the other web services to 99.9%. The actual "service" availability is in fact 99.9% x 99.9% x 99.9%. That is over a whole day per annum. To bring the "service" back to 99.9% availability, each component (if shared equally) would actually have to run at about 99.97%. That is equivalent to reducing the downtime of each component from 8 hours 45 minutes per annum to 2 hours 55 minutes. That is a big difference. If the requirement for the service was 99.99% availability, each part is only allowed just under 18 minutes outage per annum. The cost and complexity to deliver ever increasing availability can be very high. Some of the downtime can be planned and of course that the downtime all occurs at the same time, but unplanned downtime is never that conveniently stacked!
Architecting a system that is very wide and very shallow (very redundant and very independent) is easy to achieve availability and scalability with very good economics. A system that struggles to be wide at any layer and is also very deep (i.e. not easily redundant and very dependent) will struggle to achieve high availability and scalability with good economics.
Availability is not always a high priority, or not the only priority, but when it is remember to factor in the whole service not just each layer.