Teams buy a second machine and call the system highly available. A second machine on its own changes nothing. Availability is bought by three separate mechanisms that must all be present: a spare that can carry the work (redundancy), something that notices the first one stopped (detection), and something that moves the traffic (failover). Remove any one and the other two are wasted money. A spare with no detector sits idle while users see errors. A detector with no way to redirect traffic produces an alert and nothing else. A failover mechanism with nowhere to send traffic simply changes which machine returns the error. This is why the honest question in a review is never "is it redundant?" but "who notices, how long does noticing take, what moves the traffic, and how long does moving take?" The two durations add up: total downtime for one failure is detection time plus failover time, and every design choice pushes on one of them. A slower health probe with a higher failure threshold reduces false failovers and lengthens outages; a faster one does the reverse. You can now read any availability claim and ask for its three parts, and estimate the downtime a single failure will actually produce.
Failover is a high-availability technique in which a redundant machine transparently takes over for a failed one, such that a client continues addressing the same logical endpoint without being aware…