Scalability
Availability
The share of time a system is up and serving requests, quoted in nines — 99.9% is about 8.7 hours of downtime a year, 99.99% around 52 minutes. You buy it with redundancy, failover, health checks and removing single points of failure. Each extra nine costs disproportionately more, so target the level the business actually needs.
Purpose
Availability is the fraction of time a system successfully serves requests, quoted in nines: 99.9% allows roughly 8.7 hours of downtime a year; 99.99% about 52 minutes; 99.999% about 5 minutes. It is the number users actually feel — and the one written into SLAs.
When to Use It
Setting explicit targets (SLOs) per service tells engineering where redundancy is worth its cost: the checkout path may warrant four nines while an internal report tool happily lives at two. Error budgets — the allowed downtime — then govern how much risk releases may take.
Trade-offs
Each nine costs disproportionately more: multi-instance, then multi-zone, then multi-region, each multiplying infrastructure and complexity — and the added moving parts can themselves cause outages. Chasing more nines than the business needs is pure waste; know your dependency ceiling too (you cannot be more available than the services you require).
Implementation
Remove single points of failure: multiple instances behind health-checked load balancing, database failover, multi-AZ placement. Degrade gracefully (a read-only mode beats a 500 page), timeout and fail fast, measure availability from the user's side — and rehearse failure with game days rather than discovering the runbook during the outage.