You're told a service must meet a 99.95% availability NFR. Walk through how you'd translate that number into concrete architectural decisions.

## Making the percentage concrete Translating an availability NFR like '99.95%' into architecture starts with making the abstract percentage concrete. Availability targets are conventionally expressed in **nines**, and each allows a downtime budget a year: | Target | Downtime a year | |---|---| | 99% (two nines) | about 3.65 days | | 99.9% (three nines) | about 8.76 hours | | 99.95% | about 4.38 hours | | 99.99% (four nines) | about 52.6 minutes | | 99.999% (five nines) | about 5.26 minutes | The first architectural act is converting the percentage into this downtime budget, usually re-expressed per month or per quarter, because '99.95%' as a bare number gives no engineering intuition, but '21.9 minutes a month' immediately tells you whether a single planned maintenance window blows the whole budget. ## The core mechanism: eliminate the single points of failure The core mechanism for hitting an availability target is eliminating single points of failure (SPOFs) and adding automated recovery, because a system's availability is bounded above by its least-available critical-path component. If the availability of dependent components in series is roughly the product of their individual availabilities (component A at 99.99% AND component B at 99.9% in series gives roughly 99.89% combined, not 99.99%), then any single component sitting below the target availability caps the whole chain — no amount of redundancy elsewhere compensates for one unredundant link in the request path. Practically this means: - run multiple instances of every stateless tier behind a load balancer with **active health checks** so a failed instance is removed from rotation within seconds; - spread those instances across **independent failure domains** (availability zones at minimum, regions if the target and blast-radius tolerance demand it); - make the datastore redundant with **automatic failover** (e.g., a managed database with synchronous or near-synchronous replicas and an orchestrator that promotes a replica on primary failure); - remove **manual steps** from the recovery path, because a human paged at 3am adds minutes-to-tens-of-minutes that a 99.95%-or-tighter budget usually can't absorb. ## Why the number is meaningless until you draw the graph Why this exists as a distinct discipline: business stakeholders state availability as a single NFR number, but that number has no meaning until an architect converts it into a dependency graph and checks whether the graph, as designed, can mathematically achieve it. A common and costly mistake is architecting redundancy for the application tier while leaving a hard dependency on a single external API or a single-region managed service that itself only guarantees a lower number; no amount of internal redundancy raises the composite availability above that external ceiling. ## What each extra nine costs The trade-offs are steep and non-linear. Each additional nine of availability roughly multiplies the engineering and operational cost rather than adding to it linearly: - **99.9%** is achievable with multi-AZ deployment and standard managed-service SLAs; - **99.99%** typically requires multi-region active-active or fast active-passive failover, careful handling of data consistency across regions, and much more sophisticated automated failover tooling; - **99.999%** pushes into needing near-zero-downtime deployments, extremely disciplined change management, and often accepting eventual consistency trade-offs because synchronous cross-region replication at that latency budget is prohibitively slow. The architect's job is to push back on over-specified NFRs — if the business asks for 99.99% on a system whose users would genuinely tolerate an hour of monthly downtime, the extra cost (both dollars and velocity, since highly available systems are harder and slower to change safely) isn't justified by real business impact. ## How it fails in production Failure modes show up in predictable ways in production. 1. Teams add redundant instances but leave a single load balancer or single DNS record as an unnoticed SPOF. 2. They add multi-AZ database replicas but the failover is manual or takes 10+ minutes because it was never tested, so it silently caps effective availability far below the redundancy design intended. 3. They hit the target on paper by summing component SLAs additively rather than multiplying, producing an availability number that's mathematically wrong and optimistic. 4. Or they achieve high availability for reads but not writes (e.g., a single-writer database with fast read-replica failover but slow writer promotion), which matters enormously for a write-heavy service like checkout. ## A worked example on a payments API A concrete worked example: a payments API given a 99.95% NFR (≈21.9 min/month budget) is deployed as three app instances across three AZs behind an Application Load Balancer with 10-second health checks (bounding detection+removal of a bad node to under ~30s), backed by a managed relational database with a synchronous standby in a second AZ and automated failover (typically 30–120s for cloud-managed offerings). The team maps every third-party dependency in the payment-authorization path and confirms each guarantees at least 99.95%, escalating or adding a fallback/queue-and-retry path for any that don't. They validate the design isn't just theoretical by running quarterly chaos tests that kill an AZ and measure actual recovery time against the 21.9-minute monthly budget.