Overview
Availability is the fraction of time a system successfully serves requests. It is usually expressed in 'nines': 99.9% (three nines) allows about 8.8 hours of downtime per year, 99.99% about 53 minutes, and 99.999% about 5 minutes. Each extra nine is roughly ten times harder and more expensive.
High availability comes from removing single points of failure through redundancy (multiple instances, zones, regions), fast failure detection, automatic failover, and graceful degradation. Because a request often depends on many components, overall availability is the product of their availabilities, so dependencies in series reduce it and redundancy in parallel increases it.
A hospital does not rely on one power line: it has a second line, a generator, and batteries. Each backup covers a different failure, and together they keep the lights on nearly all the time.
When to use it
- Setting SLAs and SLOs for a service.
- Deciding how much redundancy to build (zones, regions).
- Evaluating the impact of dependencies on uptime.
- Interview discussions of non-functional requirements.
Where it shows up in interviews
Recognize it when: the system must be highly available.
- Design a payment system
- Design a URL shortener with 99.99% uptime
Recognize it when: survive a zone or region failure.
- Design a multi-region architecture
- Design a DNS service
Where it is used in real software
AWS, Azure, and GCP publish SLAs, such as 99.99% for multi-AZ deployments, with service credits when missed.
Amazon RDS Multi-AZ keeps a synchronous standby in another zone and fails over automatically in about a minute.
Google SRE treats 100% minus the SLO as a budget that can be spent on risky releases.
Key terms
- SLA / SLO / SLI
- Contractual promise / internal target / measured indicator.
- MTBF / MTTR
- Mean time between failures / mean time to recovery.
- Redundancy
- Extra components that take over on failure.
- Failover
- Switching traffic from a failed component to a healthy one.
- Graceful degradation
- Serving reduced functionality instead of failing completely.
How it works, step by step
- 1Define the target
Choose an SLO per user journey, such as 99.95% for checkout.
- 2Map dependencies
List every component in the request path.
- 3Remove single points of failure
Run at least two of everything across zones.
- 4Detect and fail over fast
Health checks, automatic promotion, short TTLs.
- 5Degrade gracefully
Serve cached or partial results when a dependency is down.
Downtime allowed by each availability level
Per year and per month
| Availability | Downtime per year | Downtime per month |
|---|---|---|
| 99% (two nines) | 3.65 days | 7.3 hours |
| 99.9% (three nines) | 8.77 hours | 43.8 minutes |
| 99.99% (four nines) | 52.6 minutes | 4.4 minutes |
| 99.999% (five nines) | 5.26 minutes | 26 seconds |
NOWAvailability: 99% (two nines) | Downtime per year: 3.65 days | Downtime per month: 7.3 hours
Three services at 99.9% in series give 0.999^3, about 99.7%. Two redundant instances at 99% in parallel give 1 - 0.01^2 = 99.99%.
Implementation
// Availability of components in series (all required) and parallel (any one suffices)const series = (...a: number[]) => a.reduce((acc, x) => acc * x, 1);const parallel = (...a: number[]) => 1 - a.reduce((acc, x) => acc * (1 - x), 1); const lb = parallel(0.999, 0.999); // two load balancersconst app = parallel(0.99, 0.99, 0.99); // three app instancesconst db = parallel(0.999, 0.999); // primary + standbyconst total = series(lb, app, db); const minutesPerYear = 365 * 24 * 60;console.log((total * 100).toFixed(4) + "%", Math.round((1 - total) * minutesPerYear) + " min/yr");Complexity and performance
Every dependency lowers it.
Redundancy raises it.
Trade-offs
Each additional nine typically needs more redundancy, automation, and on-call effort.
During partitions, staying available may mean serving stale data (CAP).
Variants and related techniques
All replicas serve traffic; failure just reduces capacity.
A standby takes over on failure; simpler but slower to fail over.
Common mistakes
- Ignoring hidden single points of failure.
Fix: DNS, config services, a single NAT gateway, or one deploy pipeline can take everything down.
- Redundancy never tested.
Fix: Practice failovers and chaos experiments regularly.
Interview questions
How do you design for 99.99% availability?
Run redundant instances across at least two or three availability zones, use a replicated database with automatic failover, health-checked load balancers, no single points of failure, fast rollback of deployments, and graceful degradation for non-critical dependencies.
Why does adding a dependency reduce availability?
Components in series must all be up, so the availabilities multiply. Adding a 99.9% dependency to a 99.95% service drops the combined availability to about 99.85% unless you add fallbacks.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Compute availability of a 4-tier system | Easy | Series and parallel. |
| Design a multi-AZ web application | Medium | Removing SPOFs. |