Cost vs Availability Decision Guide

Key Claims

• Availability is paid for in money; the bill is non-negotiable. Each additional nine of availability is roughly 10× the engineering cost. Five nines is not a target you reach with effort; it's a target you reach with budget.
• 100% is always the wrong target (SRE). Past user-perceptible thresholds, additional nines consume engineering capacity that could buy features. The target is set by user impact, not technical aspiration.
• Downtime cost is the conversion rate between availability and money. A high-traffic e-commerce site loses $3K/minute at peak. Five minutes of monthly downtime over five years = $900K. A $50K investment that prevents it returns 18×.
• Dependencies multiply availability cost. Each dependency degrades the upper bound: five services at 99.9% give 99.5% in series. To reach high availability with many dependencies, reduce dependency depth, isolate fault domains, or accept degraded responses.
• MTTR matters more than MTBF at scale. At hyperscale, failure is constant. Recovery speed is the lever. Allspaw's argument; SRE operationalises it.
• Tyranny of the nines is the dominant antipattern. Specifying availability without specifying what for. Negotiate per-feature: does the entire system need five nines, or only the transaction core?

Why This Page

Availability covers the mechanics. Cost As Architectural Force covers the economics. This page is the decision — given a desired availability, what's the cost? Given a budget, what availability is realistic? When does each technique earn its cost?

The Nines Table (with money attached)

The standard nines table, extended with cost framing:

Each additional nine is roughly 10× the engineering cost. The question is never "can we reach five nines?" but "what does five nines cost, and is it worth it?"

The Conversion: Downtime Cost

Availability becomes financial when you multiply downtime by cost-per-minute-of-downtime.

Annual downtime cost = (1 − SLO) × hours_in_year × cost_per_hour_of_downtime

Estimating cost-per-hour-of-downtime:

The investment threshold. If a one-time investment of $X eliminates Y hours of downtime per year over a 5-year asset life:

ROI = (Y × hours/year × cost_per_hour × 5 years) / X

Release It ch. 1's canonical example: $50K invested in zero-downtime deployment vs $900K downtime cost over 5 years = 18× ROI. The maths makes the case.

The Decision Tree

Q1: What does the user actually need?

The first question is almost always under-asked. "Five nines" specified without justification is the dominant antipattern.

• What user activities matter? (login, purchase, view, edit)
• What's the user's tolerance threshold? (annoyed at 1s, leaves at 3s, complains at downtime > 5 min, files support ticket at downtime > 1 hr)
• Is the system used continuously, or in bursts? (5 min downtime at 3am vs 5 min downtime during Black Friday)
• Is there a fallback? (cached data, queue, retry-later) — fallback availability adds to the user-visible nines.

The honest answer is often "99% is fine for this feature; 99.9% for the transaction core." That's two SLOs, not one — see Q4.

Q2: What does downtime cost us?

For each minute of downtime:

• Direct revenue lost (transactions not completed).
• Customer trust degraded (churn risk, NPS hit).
• SLA penalties (contractual credits, refunds).
• Engineering response cost (incident response, postmortems, remediation work).
• Opportunity cost (features not built while firefighting).

Sum these per minute of downtime. Multiply by minutes of downtime per year at each candidate SLO. The differences between SLO levels are real money.

Q3: What does the investment cost?

For each additional nine, what investments are required?

Each step is a discrete investment. Total cost: engineering time, infrastructure cost, operational overhead, organisational discipline. These compound — the operational overhead of a five-nines system is not 10× a four-nines system; it's qualitatively different.

Q4: Can you set different SLOs for different features?

This is usually the right answer. The same system rarely needs the same availability everywhere.

Common pattern:

• Transaction core (checkout, payment, account changes): five nines. High investment justified by direct revenue impact.
• Read paths (browse, search, view): four nines. Important but degradation possible.
• Discovery / recommendations: three nines. Falls back to cached or simpler results.
• Analytics, reporting, admin: two nines or less. Background work; degradation acceptable.

The architectural implication: feature-level isolation. Bulkheads (Bulkhead), cellular architecture, graceful degradation under load. The five-nines core is small enough to be designed for it; the rest of the system trades off cost for the bulk of features.

Where Each Nine Is Earned

The big chunks of availability investment, ordered by typical ROI.

High ROI: 90% → 99% → 99.9%

Cheapest investments:

• Multi-AZ deployment (often a flag on a managed service).
• Health checks and automated load-balancer removal of failed instances (Load Balancing).
• Timeout on every external call.
• Basic Monitoring and alerting on user-visible SLIs.
• Automated deployment pipelines (Deployment Pipelines) so deploy time doesn't dominate downtime.
• Progressive Delivery to limit blast radius of bad releases.

Most teams have done these but treat them as one-time setup. Continuous attention (updates, dashboards, runbook freshness) keeps them earning.

Medium ROI: 99.9% → 99.99%

• Multi-region deployment (active-active or active-passive).
• Circuit Breaker, Bulkhead, Retry applied at every integration point (Stability Pattern Selection).
• Chaos Engineering to verify failure modes work as designed.
• Error Budgets to gate aggressive change against reliability impact.
• Investment in MTTR: better tooling, better runbooks, on-call training.
• Backups + restore drills (Data Integrity).

The transition from three nines to four is mostly about reducing MTTR rather than reducing MTBF. The cost is real but bounded.

Diminishing ROI: 99.99% → 99.999%

• Cellular / cell-based architecture (each cell isolated; failure of one cell affects 1/N of users).
• Per-cell capacity and operational isolation.
• Automated remediation (not just alerts → runbook, but alerts → automated action).
• Dedicated SRE organisation with operational authority.
• Capacity for rapid rollback at every layer (database, code, schema).

Past this point, the system organisation, not just the architecture, has to be designed for it.

Very Diminishing ROI: 99.999% → 99.9999%

• Specialised hardware (redundant network paths, hot-spare data centres).
• Formal verification of critical components (TLA+ on consensus, migration procedures).
• Rigorous change management; long bake periods; multiple approval gates.
• The organisation becomes risk-averse to features in service of availability.

Rare outside life-critical systems. For most businesses, the user impact of moving from five nines to six nines is invisible while the cost is large.

When Each Investment Earns Its Cost

A few rules of thumb for evaluating specific availability investments.

Multi-AZ deployment almost always justifies itself for any business-critical service. The cost is modest (some additional infrastructure spend, cross-AZ traffic cost); the benefit is taking AZ failures off the table.

Multi-region is harder to justify. The cost is high (data replication across regions, cross-region traffic, additional operational complexity). The benefit is taking regional failures off the table. Most businesses don't experience regional failures often enough for this to clear ROI unless availability requirements are very high.

Chaos engineering (Chaos Engineering) earns its cost by surfacing problems before they cause incidents. Its ROI is hard to measure directly ("the incident that didn't happen") but Kirkpatrick-Level-2 metrics like "vulnerabilities discovered before user impact" support the case.

Zero-downtime deployment (Release It ch. 1's canonical example): 18× ROI over 5 years for typical e-commerce. Almost always justifies itself if you deploy more than monthly.

Investment in MTTR (Incident Management) typically out-earns investment in MTBF (preventing failure) at scale. Where MTBF approaches zero anyway, MTTR is the active lever.

Backups and restore drills (Data Integrity) have very high ROI because the failure mode they prevent (data loss) is unbounded. Test the restore; an untested backup is no backup.

Anti-Patterns

Specifying availability without specifying scope. "The system needs five nines" without saying which features need five nines is the most expensive failure mode. The default cost is to make the entire system five nines, which is usually overkill and often not feasible.

Treating availability as a technical decision. Availability targets are business decisions. The conversion to money (Q2 above) makes the trade-off real. Engineers should not unilaterally accept availability targets without business sign-off on the cost.

100% as a target. SRE's central argument: 100% is always wrong. Users have tolerance thresholds; past those, additional availability is invisible. Push the target to "what users can tell the difference at" and stop.

Tyranny of the nines. Targeting four nines because four nines sounds better than three. The right level is the lowest level that meets user need; one nine higher costs 10× more.

MTBF investment without MTTR investment. Preventing failure is harder and more expensive than detecting + recovering from it. Both matter; in mature systems, MTTR is usually the dominant lever.

Redundancy without isolation. Two database replicas behind a shared load balancer are not redundant from the load-balancer's perspective. Redundancy must extend to every shared dependency; otherwise the unshared component is the SPOF.

Adding investment without removing risk. A new auto-scaler, a new fallback path, a new monitoring system — each one adds complexity, and complexity itself reduces reliability. Counter-intuitively, removing complexity often increases availability more than adding redundancy does (see Chaos Engineering's "three counter-intuitive rules").

SLA penalties as the only motivation. SLAs are external contracts; SLOs are internal targets. Targeting "just above the SLA" makes the SLA the operating point, which means every minor incident risks breaching it. Set SLOs comfortably above SLAs.

The Architectural Implications

High availability isn't just operational discipline; it's an architectural property. Some architectures make high availability cheap; others make it expensive.

Cheaper to achieve high availability:

• Stateless services (Scalability) — failed instances replaceable without coordination.
• Bulkhead architecture (Bulkhead) — partition-level failures don't propagate.
• Asynchronous communication (Sync Vs Async Communication) — no temporal coupling between availability of services.
• Cellular architecture — cell-level isolation contains failures.
• Read replicas + eventual consistency (Consistency Models) — reads survive write-tier failures.

Expensive to achieve high availability:

• Distributed transactions (2PC) — coordinator failure blocks. See Distributed Transactions.
• Synchronous service chains — availability multiplies down the chain.
• Shared databases — SPOF; coupling all callers' availability to one component.
• Strong consistency across regions — requires consensus, which has hard latency and availability trade-offs (Consensus Algorithms).

The architectural choice precedes the availability investment. A distributed monolith will never reach five nines cheaply. The investment goes into changing the architecture, not into adding redundancy to a fragile one.

How Different Sources Treat It

Related Concepts

• Availability — the mechanics of availability
• Cost As Architectural Force — cost as a first-class quality attribute
• Error Budgets — operational mechanism for negotiating reliability vs change
• Site Reliability Engineering — the discipline behind these decisions
• Stability Patterns — the pattern set that earns the nines
• Stability Pattern Selection — selecting and composing those patterns
• Performance And Capacity — performance investment with similar ROI logic
• Progressive Delivery — limiting blast radius of releases
• Chaos Engineering — verifying availability investments actually work
• Data Integrity — availability vs data integrity (orthogonal concerns)
• Monitoring — SLI/SLO definition and burn-rate alerting
• Incident Management — MTTR as the active lever
• Architecture Characteristics — availability in the trade-off framework
• Architecture Styles — style choice as availability ceiling