Availability Fundamentals

Availability Math

Availability is the fraction of time a system is operational and reachable. It is expressed as a percentage and calculated by dividing uptime by total time. The difference between 99.9% and 99.99% availability is the difference between 8.76 hours and 52.6 minutes of downtime per year.

SLIs, SLOs, and SLAs

Service Level Indicators (SLIs) are the raw measurements of your system's behavior. Service Level Objectives (SLOs) are the target values for those indicators. Service Level Agreements (SLAs) are the contractual commitments backed by financial penalties.

service: payment-gateway
slo:
  - indicator: availability
    target: 99.95%
    measurement_window: 30_days
    error_budget: 21.6_minutes
  - indicator: latency_p99
    target: 200ms
    measurement_window: 30_days
    error_budget: 5%_of_requests

Error Budgets

An error budget is the inverse of your SLO. If your SLO is 99.95% availability, your error budget is 0.05% — the amount of allowable downtime. Error budgets turn reliability into a shared resource between engineering and product teams.

1. When the error budget is healthy, product teams can ship faster with less polish.
2. When the error budget is consumed, feature freezes are enforced to prioritize reliability.
3. Error budgets create alignment — everyone shares the same reliability incentive.
4. Burn rate measures how fast you are consuming the error budget.

The Nines

Each additional nine of availability is exponentially harder and more expensive to achieve. Going from 99.9% to 99.99% typically costs 10x more in redundancy, monitoring, and operational overhead. The decision of how many nines to target should be driven by business requirements, not engineering pride.

Failure Domains

A failure domain is a portion of your infrastructure that can fail independently. The goal of HA design is to minimize the blast radius of any single failure. Common failure domain boundaries include: racks, availability zones, regions, and clouds.

Cloud Provider (external)
 └── Region A
      ├── Availability Zone 1 (AZ)
      │    ├── Rack 1
      │    │    ├── Server 1
      │    │    └── Server 2
      │    └── Rack 2
      └── Availability Zone 2 (AZ)
           ├── Rack 3
           └── Rack 4

Designing for Availability

High availability is not a feature you add at the end. It is a property that emerges from deliberate architectural decisions made at the beginning. Eliminate single points of failure, use redundancy across failure domains, and design for graceful degradation.

• No single point of failure — every critical path has at least one redundant component.
• No correlated failures — redundancy across independent failure domains.
• Fast detection — monitoring and alerting that catch issues in seconds.
• Fast recovery — automated failover and self-healing mechanisms.