High Availability

High availability is a system's ability to keep operating even when one of its components fails. It does not mean nothing ever breaks: it means that one part breaking does not bring the service down, because another one is ready to take over. In practice, it is the work of removing the points where a single failure stops everything.

By the percentage of time the system is available over a year, and the industry shorthand counts the nines after the decimal point. In a year of 8,766 hours: 99% allows 3 days and 15 hours of downtime; 99.9%, the three nines, allows 8 hours and 45 minutes; 99.99%, four nines, allows 52 minutes and 35 seconds; and 99.999%, five nines, allows 5 minutes and 15 seconds. That is why the number has to be chosen by the business and not by IT: every extra nine costs real money.

The gap between three and four nines is the gap between 8 hours 45 minutes and 52 minutes of downtime a year. It looks small as a percentage and is enormous in operation: the first accepts a whole morning offline, the second will not accept even an hour. That step is usually what justifies investing in redundancy, and it is where the cost changes scale.

It is any component whose failure takes the whole service down on its own: a server with no pair, a single internet link, one power supply, a storage array with no mirror. High availability is, in practice, the work of finding and removing those points. The assessment usually turns up points the internal team had not mapped.

Four of them, working together. Redundancy means having more than one component doing the same job, so one going down does not stop the service. Load balancing distributes requests between them and takes the failed one out of rotation. Failover is the automatic switch to the standby component, with no manual intervention. And backup is the safety net for the case where the data is lost, not just the hardware.

High availability keeps the service standing when a component fails, and ideally the user never notices. Disaster recovery is what you invoke when the whole environment is lost, and then there is a declared outage and a recovery plan. One works in seconds, the other in hours. Both are needed and neither replaces the other.

No, and relying on that is an expensive mistake. Redundancy and replication copy whatever happens, including what should not: if data is deleted by accident or encrypted by ransomware, the redundant node receives the same change. A backup holds the previous state, and it is the only thing that brings the data back in that scenario.

By the cost of downtime, not by the ambition of the number. It is worth calculating what the company loses per hour offline, counting revenue, contractual penalties and rework, and comparing that with the cost of each additional nine. Different systems usually deserve different levels: not everything needs five nines.

It does not remove maintenance, but it lets you do it without taking the service down. With redundancy and failover, you update one node at a time while the others keep serving. The maintenance window stops being an outage and becomes a procedure.

Both, and in hybrid arrangements. The design starts from an assessment of the current environment, the single points of failure found in it, and the availability level the business needs to sustain.