Documentation / Platform glossary / High availability
High availability is designing a system so that expected component failures do not interrupt service. It assumes hardware fails, processes crash, and instances are replaced, and arranges for those events to be absorbed automatically rather than escalated to an outage.
Three elements make availability real, and all three are required.
Redundancy means no single instance of anything is required for the system to function. Health checking means failures are detected quickly and accurately — a check that only confirms a process is running will happily route traffic to an instance that cannot serve requests. Automatic failover means traffic moves away from unhealthy capacity without human intervention, because a design that needs an engineer to intervene is not highly available at 3am.
Availability is conventionally expressed in nines, and the practical difference is easy to underestimate. 99.9% allows roughly 8.8 hours of downtime a year; 99.99% allows about 53 minutes. Each additional nine costs substantially more and constrains how the system can be operated.
High availability is distinct from disaster recovery, and conflating them leads to unpleasant surprises. High availability handles component failure continuously and automatically within an environment. Disaster recovery handles the loss of that environment and generally requires a decision to invoke. A system can be highly available and still lose everything if its single region becomes unavailable.
The failure mode that defeats redundancy is a shared dependency — a component every replica relies on. Redundant application instances behind a single point of failure are not redundant in any meaningful sense.
For a system a workforce depends on daily, availability is a business requirement rather than a technical preference. It also interacts directly with contractual commitments, since an SLA is the point where availability becomes an obligation with a remedy.
For an evaluator, the substantive questions concern shared dependencies and whether failover is tested — not the number of nines claimed.
QueryTek runs redundant capacity with health-based traffic management so that losing an individual component does not remove a capability. Public documentation describes the practice; cluster layouts, failover procedures, and uptime figures beyond approved claims are not published.
