Reliability & Performance
Redundancy & Failover
Running duplicate components so that if one fails, another takes over automatically, the mechanism behind high availability.
Redundancy is having spares, more of a component than you strictly need, so a failure has somewhere to fall back to. Failover is the act of switching to the spare when the primary dies, ideally automatically and fast enough that users barely notice. Together they're the machinery that makes high availability real rather than aspirational.
It shows up at every layer. Two app servers so one can die. A standby database that gets promoted when the primary fails. DNS-level failover that reroutes traffic away from a dead region. A load balancer that stops sending requests to an unhealthy backend. Each is a form of "if this breaks, that takes over," and managed services increasingly build failover in so you don't hand-roll it.
The detail that decides whether redundancy works is testing. A failover path that's never been exercised is a guess, and outages love to reveal that the standby was misconfigured or the promotion never actually triggered. The teams that stay up are the ones who deliberately break things to prove the fallback works.