Availability vs Reliability vs Durability: Precise Definitions for Engineers

Three statements from one incident review: “The database was up, so the service was available.” “It returned stale account balances, so it wasn’t behaving correctly.” “And the transactions we acknowledged before the crash are gone.” All three speakers are right, about three different properties. Availability, reliability, and durability fail separately, are engineered separately, and are conflated constantly. Precise definitions matter because you cannot design, measure, or buy a property you have not defined.

Availability is the fraction of time a system responds to requests. Reliability is the probability that the system behaves correctly over a period of use. Durability is the guarantee that once a write has been acknowledged, the data survives failures. A system can have any combination of the three, including none.

These definitions are the canonical ones used across this library’s distributed-systems articles.

Availability: the uptime story

Availability measures whether the system responds, not whether the response is right, fast, or fresh. Formally:

Availability = uptime / (uptime + downtime)
             = MTBF / (MTBF + MTTR)

MTBF, mean time between failures
MTTR; mean time to restore (detect + repair + recover)

The two levers are visible in the formula: fail less often (raise MTBF) or recover faster (cut MTTR). Engineering usually attacks MTTR first because it is cheaper: redundancy, automated failover, and faster restores buy availability faster than eliminating every failure cause.

The nines

Two readings of this table are common and wrong. First, the nines measure time, not quality of responses; a system that answers every request instantly with wrong data is 100% available. Second, each additional nine is roughly an order of magnitude more expensive in redundancy, testing, and automation. Five nines allows about five minutes of downtime per year (less than one deploy gone wrong) so claims beyond four nines deserve scrutiny of how the number is measured.

What counts as “down”?

An availability number is meaningless until “responds” is defined. Does a load balancer’s 503 count? A 200 with a 30-second response? A successful checkout that never records the order? A serious availability definition specifies: which requests, measured from where, with what status codes, within what time limit. Client-side measurement from real traffic beats server-side dashboards, which only see the requests that reached them.

How availability is engineered

Redundancy plus failover. At least two of everything; servers (load balancing routes around dead nodes), data copies (database replication), network paths, power. Then automation to move traffic without a human in the loop. Fault tolerance (a system’s ability to keep operating despite component failures) is the mechanism; availability is the outcome. The mechanism gets its own deep dive in fault-tolerant systems.

Reliability: the correctness story

Reliability asks the question availability skips: did the system do the right thing?

Over an interval of use, reliability is the probability that the system performs its intended function correctly: serving accurate results, losing nothing, corrupting nothing, charging each card exactly once. A system can be perfectly available and perfectly unreliable: consider a search index that silently stopped updating months ago and has been cheerfully serving stale results ever since. Uptime: flawless. Correctness: zero.

Reliability subsumes availability as a special case (a system that does not answer is not behaving correctly either) but adds correctness of the answers:

• Right data. Reads return current, accurate values. What “current” can even mean in a distributed system is formalized in the CAP theorem and consistency models.
• No loss. Every acknowledged request persists, the durability property below.
• No duplication. Operations produce their effect exactly once, usually via idempotency keys and exactly-once processing patterns. The hard version is distributed transactions.
• In-order effects. Where ordering is part of the contract, messages and updates apply in a defensible order.

Faults versus failures

A fault is a component deviating from spec; a disk reporting bad blocks, a replica falling behind, a network path slowing down. A failure is the system as a whole violating its contract. Fault tolerance is the art of absorbing faults so they never become failures: redundancy masks the fault entirely, graceful degradation shrinks the blast radius, and fallbacks trade features for uptime. The distinction matters because you cannot reason about reliability until you list the faults you intend to survive. That taxonomy is the subject of fault-tolerant systems.

Durability: the data-survival story

Durability answers one question: once a write is acknowledged, does it survive failures?

A durable system can crash, lose power, and restart with every acknowledged write intact. Durability lives at the storage layer, built from three ingredients:

• Write-ahead logs and forced flushes. The database records the change on disk (fsync) before acknowledging it. The milliseconds this costs are the price of the guarantee, a latency/consistency trade spelled out in the CAP theorem and latency vs throughput.
• Replication across failure domains. Copies on independent machines, racks, and zones, so one physical event cannot destroy the only copy (database replication).
• Erasure coding or mirrored storage in distributed systems, so disk loss means recovery, not data loss.

As a calibration point, commercial object stores advertise durability in exponents of nines; Amazon S3’s published figure is 99.999999999% (eleven nines) per year; achieved through replication and erasure coding, not through any single disk being reliable.

Durability is not availability

The two fail in opposite directions, which is why conflating them produces bad architecture:

• Durable but unavailable: the archive with every byte intact, behind a down API. Storage that is safe but unreachable serves nobody.
• Available but not durable: the in-memory cache that answers everything at microsecond speed and forgets it all on restart.

Backups sit awkwardly between the two and deserve their own note: backups are recovery, not durability. A backup restores data lost from the primary; durability means the primary never acknowledges a write it can lose. A system with backups still has a window (the recovery point objective) in which acknowledged data can be lost and then restored. Durable systems close that window; backups bound it.

Where the three trade off

Every guarantee here costs one of the others, usually latency or money:

Read a row and a system appears; this is the design space every replicated datastore occupies. The formal treatment of the consistency/availability tension is the CAP theorem; the engineering of the “keep serving anyway” half is fault-tolerant systems.

SLIs, SLOs, and SLAs: putting numbers on these properties

• SLI, service level indicator: the measurement itself. “Successful requests ÷ total requests, measured client-side, excluding requests slower than 2 s.” Availability, error rate, and latency percentiles (latency vs throughput) are the classic SLIs.
• SLO, service level objective: the internal target. “99.9% availability per rolling 30 days.” Objectives bind all three properties from this article: availability nines, an error-rate ceiling, a latency percentile target.
• SLA, service level agreement: the external contract, with consequences: credits, penalties, exit clauses. SLAs are lawyers’ SLOs: looser, carefully scoped, measured with the vendor’s own tools.
• Error budget: one minus the SLO. A 99.9% availability SLO allows about 44 minutes of downtime per month; that is the budget. Teams spend it deliberately: on deploys, risky migrations, experiments. When the budget is spent, releases freeze. Error budgets convert reliability from a moral argument into arithmetic.

Common mistakes

• Counting answers as availability. A load balancer that returns 503s is up; the service is not. Availability must be measured from the client, with status codes and time limits defined.
• Chasing nines without defining “down.” Five nines without a precise definition of downtime is marketing, not engineering.
• Equating replication with backups. Replication protects against node loss with no loss window; backups protect against logical destruction (a bad migration, a dropped table) with a loss window. Production systems need both, and neither substitutes for the other.
• Treating fault tolerance as availability. Fault tolerance is a mechanism (survive component failure); availability is an outcome (measured uptime). You build the first and measure the second; assuming the second from the first is how systems pass health checks while failing users.
• Ignoring durability until after the first data-loss incident. The fsync and replica-acknowledge costs are milliseconds today; the audit after losing acknowledged writes costs far more.

FAQ

Can a system be highly available but unreliable?

Yes; it is the most common real-world failure shape. The service answers every request, on time, with stale or wrong data: an un-updated index, a desynchronized replica, a silently broken pipeline. Uptime dashboards stay green while correctness rots.

How much downtime is 99.9% availability?

About 8.8 hours per year, or roughly 44 minutes per month. Each additional nine divides the allowance by ten: four nines is about 53 minutes per year.

Is durability more important than availability?

Neither dominates; the product decides. A payments ledger needs durability even at latency cost; acknowledged money movements must survive. A social feed tolerates a rare lost update but cannot tolerate being unreachable. Design each component around its own worst-case regret.

What is the difference between fault tolerance and high availability?

Fault tolerance is the ability to keep operating correctly through component failures; high availability is the measured outcome of maximizing uptime. Fault tolerance plus fast failover is how you get high availability: a mechanism, not a metric.

Do backups make a system durable?

No. Backups bound how much acknowledged data can be lost (the recovery point objective) and how long recovery takes (the recovery time objective). Durability means no acknowledged write is lost at all. Backups protect against the failures durability cannot address, such as logical corruption replicated faithfully to every replica.

Related articles

• Next read: the CAP theorem and consistency models, why consistency, availability, and partition tolerance cannot all be guaranteed at once.
• fault-tolerant systems, the engineering of surviving failures.
• database replication, how durability and availability are built at the data tier.
• latency vs throughput; the other two performance numbers every design must state.

Last updated on 8 September 2026