Reliability & Performance
High Availability
Designing a system with no single point of failure, so it keeps running even when individual components fail.
High availability means the system survives its parts failing. No single server, disk, or zone can take the whole thing down, because there's always another component ready to carry the load. It's achieved by removing single points of failure: multiple app servers behind a load balancer, a database with an automatic standby, resources spread across availability zones.
The jump from a single server to HA is the biggest reliability step you can take, and it's where architecture matters more than the host's SLA. One machine, however good its provider's uptime promise, still fails sometimes. Two machines behind a load balancer, with a database replica ready to promote, keep serving through a failure that would have been an outage.
HA costs more, in duplicated resources and in complexity, so it's a deliberate trade rather than a default. A hobby project doesn't need it. A revenue-critical service does, and the components, load balancers, read replicas, multi-zone deployment, are exactly the building blocks that make it possible.
Go deeper
- What an Uptime SLA Actually GuaranteesHow to read "99.9% uptime," what providers actually owe you when they miss it, and why the number matters less than the fine print.