Availability
Users and businesses depend on systems being available. A payment system that goes down for 1 hour can cost millions of dollars.
Quick answer: Availability
Availability is covered here as a practical system design concept. Users and businesses depend on systems being available. A payment system that goes down for 1 hour can cost millions of dollars. Use it to understand the Core Concepts idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
The Core Idea
Availability is the percentage of time a system is operational and accessible to users. It is typically measured in 'nines' — 99.9% (three nines) means at most 8.76 hours of downtime per year, while 99.99% (four nines) means at most 52.6 minutes per year.
Step-by-Step Walkthrough
High availability is achieved through eliminating single points of failure (SPOFs). Every layer of the system must be redundant: multiple application servers behind a load balancer, database replication across availability zones, multi-region deployment for disaster recovery. When a component fails, the system automatically detects the failure (via health checks or heartbeats) and routes around it (via failover or load balancer reconfiguration).
The key formula: System availability = Component1 availability × Component2 availability × ... For a system with 3 components each at 99.9%, total availability is 0.999³ = 99.7%. This means you must design each component for higher availability than your target.
Why This Approach Wins
- Redundancy is the foundation of availability. Every critical component must have at least one backup — redundant servers, databases, network paths, and data centers.
- Failover is the process of switching to a backup when the primary fails. It can be active-passive (standby takes over) or active-active (both handle traffic, one absorbs the other's load).
- Health checks detect failures. Load balancers ping servers every few seconds. If a server stops responding, traffic is routed away within seconds.
- Graceful degradation means the system continues to function at reduced capacity rather than failing completely. Netflix shows cached recommendations instead of nothing when its recommendation service is down.
- Measuring availability: Availability = Uptime / (Uptime + Downtime). Each additional 'nine' requires exponentially more engineering effort and cost.
In Production
AWS designs for 99.99% availability in each region by distributing services across multiple Availability Zones (physically separate data centers connected by low-latency links).
Google targets 99.999% availability for Gmail by using globally replicated storage (Spanner) and automated failover between data centers.
Stripe maintains payment processing availability through redundant payment processors, database replicas, and a global edge network.
Tradeoffs and Limitations
- Availability vs. Consistency: The CAP theorem states you cannot have both perfect availability and perfect consistency in a distributed system during a network partition.
- Cost vs. Nines: Each additional nine of availability roughly doubles the infrastructure cost.
- Complexity vs. Reliability: More redundancy means more components to manage, monitor, and coordinate.
Production Gotchas
- Not accounting for correlated failures — if all replicas are in the same data center, a power outage takes them all down
- Assuming cloud services are always available — even AWS has multi-hour outages
- Not testing failover — an untested failover mechanism is not a failover mechanism
- Ignoring cascading failures — one overloaded service can bring down the entire system
The Interview Angle
- How do you design a system for 99.99% availability?
- What is the difference between high availability and fault tolerance?
- How do you handle failover without losing data?
- What are the tradeoffs between availability and consistency (CAP theorem)?
Next Up
Original DosiBridge notes for Availability
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Availability is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- SLO: For Availability, decide the SLO before choosing tools; otherwise the design looks clean but fails when availability changes.
- Capacity Headroom: For Availability, decide the capacity headroom before choosing tools; otherwise the design looks clean but fails when availability changes.
- Failure Mode: For Availability, decide the failure mode before choosing tools; otherwise the design looks clean but fails when availability changes.
- Degradation Path: For Availability, decide the degradation path before choosing tools; otherwise the design looks clean but fails when availability changes.
- Operator Signal: For Availability, decide the operator signal before choosing tools; otherwise the design looks clean but fails when availability changes.
Distinct angle: availability is user-journey uptime
Availability should be measured per critical journey, not only per server. A checkout page can be mostly available while coupon validation is degraded; a messaging app can remain useful with delayed attachments. This page's distinct angle is choosing which features degrade first and which journey must remain alive during partial failure.
Production review question
If a team adopts Availability, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track availability health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Availability, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.