High availability versus fault tolerance

WHAT THIS TESTS The interviewer wants to know if you understand resilience as a spectrum rather than a binary, and whether you can reason about cost and complexity trade-offs at each tier.

A GOOD ANSWER COVERS High availability aims to minimize downtime, accepting that brief outages may occur during a failover event. It is usually measured in nines of uptime. Fault tolerance is stronger: the system continues operating with no perceptible interruption even when a component fails. HA tolerates recovery time; fault tolerance tolerates zero. A good answer notes that fault tolerance costs more because it demands redundancy at every layer and replicated state.

COMMON WRONG ANSWERS Treating the two terms as interchangeable. Claiming that spreading instances across availability zones automatically yields fault tolerance, while ignoring shared state, in-flight requests, and the database tier. Forgetting that the data layer is usually the hardest part.

LIKELY FOLLOW-UPS How do you handle session state during failover. What is the difference between synchronous and asynchronous replication and how does each affect recovery point objective. How would you test the failover path.

ONE CONCRETE EXAMPLE A highly available setup might place an application load balancer in front of two web servers in separate availability zones, backed by a primary database with a standby replica that promotes on failure. There is a short window during promotion where requests fail. To make it fault tolerant, you add active-active web servers with no sticky local state, externalize sessions to a replicated store, and run the database in a synchronous multi-writer or quorum configuration so a node loss never drops a transaction. You also remove single points of failure such as a lone NAT gateway. The trade-off is roughly double the infrastructure spend and far greater operational complexity, which is why most teams choose HA unless the workload genuinely cannot tolerate any interruption.