beginnerintermediateadvanced

System Design · Availability, Reliability and Durability

Availability, Reliability and Durability

Three distinct guarantees, what each "nine" actually allows, and the toolkit that earns them

Three guaranteesreachable, correct, data preserved
The nines99% ≈ 3.65 days/yr down · 99.999% ≈ 5 min/yr
Seven techniquesredundancy, failover, backups, DR, and more
No hidden SPOFswalk the whole path before claiming HA

1.Availability, reliability and durability

Three related but distinct guarantees: availability is the percentage of time a service can be reached and used; reliability is the probability it behaves correctly while it runs; durability is the probability that data already stored stays intact, even during downtime.

Key features

Availability: can the service be reached and used right now — measured as % uptime
Reliability: does the system behave correctly while running — measured as failure probability over time
Durability: is stored data preserved, even across crashes or outages — measured as data-loss probability
A system can be available but unreliable (up, but returning wrong answers)
A system can be unavailable but still durable (down, but no data lost once it returns)

The three guarantees

The three guarantees
Term	Answers	Failure looks like
Availability	"Can I reach the service right now?"	timeouts, connection refused, 503s
Reliability	"Does it behave correctly while running?"	wrong results, crashes mid-request, silent bugs
Durability	"Is data I already stored still there?"	data loss after a crash, disk failure, or bad deploy

A database node crashes during a write — two different verdicts

Availability (took a hit)

Service returns errors for 90 seconds
A replica must be promoted first
"Can I reach it?" — no, for 90s

Durability (held)

The write was already replicated to 2 nodes
No committed data was lost
"Is it still there?" — yes

Command

text

availability = uptime / total_time            (can I reach it?)
reliability  = P(correct behavior over time)   (does it work right?)
durability   = P(stored data is not lost)      (is it still there?)

Availability = can you reach it; reliability = does it work correctly; durability = is stored data preserved. Different questions, different failure modes.

2.Uptime "nines" and what they allow

Each additional "nine" of availability shrinks allowed downtime by roughly 10x. 99% allows about 3.65 days of downtime a year; 99.999% ("five nines") allows about 5 minutes — and each step up costs disproportionately more engineering effort.

Key features

99% ("two nines"): ~3.65 days/year downtime — a single-server app with manual restarts
99.9% ("three nines"): ~8.76 hours/year — needs monitoring and fast manual or semi-automated recovery
99.99% ("four nines"): ~52.6 minutes/year — needs automated failover, redundancy across zones
99.999% ("five nines"): ~5.26 minutes/year — needs multi-region redundancy, near-zero manual intervention
Each additional nine costs disproportionately more engineering and operational effort, not a proportional amount

Availability targets and allowed downtime

Availability targets and allowed downtime
Availability	Downtime / year	Downtime / month	Typical requirement
99% ("two nines")	~3.65 days	~7.3 hours	single instance, manual recovery acceptable
99.9% ("three nines")	~8.76 hours	~43.8 minutes	monitoring + fast on-call response
99.99% ("four nines")	~52.6 minutes	~4.4 minutes	automated failover, multi-zone redundancy
99.999% ("five nines")	~5.26 minutes	~26 seconds	multi-region, near-instant automated failover

Each nine: 10x less downtime, 10x more engineering effort

Almost none allowedMore downtime allowed

Low effortHigh effort

99% (~3.65 days/yr): single instance, manual recovery
99.9% (~8.76 hr/yr): monitoring + fast on-call
99.99% (~52.6 min/yr): automated failover, multi-zone
99.999% (~5.26 min/yr): multi-region, near-instant failover

Command

text

allowed downtime = total_time × (1 - availability)

525,600 minutes/year × (1 - 0.999) ≈ 525.6 min ≈ 8.76 hours

99% ≈ 3.65 days/yr down · 99.9% ≈ 8.76 hr/yr · 99.99% ≈ 52.6 min/yr · 99.999% ≈ 5.26 min/yr — each nine is ~10x tighter.

3.The redundancy and recovery toolkit

Seven concrete techniques back the three guarantees: redundancy (extra capacity), failover (switching to it), health checks (detecting failure), graceful degradation (partial function over total failure), backups and replication (protecting data), and disaster recovery (a plan for large-scale loss).

Availability and durability techniques

Availability and durability techniques
Technique	Defends against	Example
Redundancy	a single component failing	two app servers instead of one
Failover	the active component going down	traffic auto-routes to the standby
Health checks	not knowing a component has failed	a load balancer pings /health every 5s
Graceful degradation	total failure when one dependency fails	serve cached results if the DB is slow
Backups	data corruption or accidental deletion	nightly snapshot, restorable point-in-time
Replication	losing the only copy of live data	writes copied to 2+ nodes in real time
Disaster recovery	a whole region or datacenter loss	documented plan + tested failover to another region

Seven techniques, four guarantees, one incident

Stays available

Redundancy

App servers and replicas already running in two other zones

Health checks

The load balancer notices the zone stop responding within 10 seconds

Failover

Traffic reroutes to the healthy zones without waiting for a human

Stays usable

Graceful degradation

Recommendations lived in the failed zone and are skipped; the page still renders

Stays durable

Replication

A replica in a healthy zone is promoted; no committed writes are lost

Backups

A point-in-time copy — it recovers the corruption replication would have copied

Survives the big one

Disaster recovery

Not invoked here — one zone was absorbed. This is for a whole region

Command

text

redundancy + health checks + failover  -> stays available
graceful degradation                    -> stays usable when partial
backups + replication                   -> stays durable
disaster recovery                       -> survives large-scale loss

Redundancy + health checks + failover keeps a system available; graceful degradation keeps it usable when partial; backups + replication keep data durable; disaster recovery covers large-scale loss.

4.Never claim high availability without ruling out single points of failure

A single point of failure (SPOF) is any one component whose failure takes down the whole system. An availability number is only credible once every SPOF in the design has been named and explicitly accepted or removed — not assumed away.

Walk the whole path, not just the tier you made redundant

The claim looked at one layer. Walking every layer found two components that each take the whole system down.

Command

text

overall availability ≈ the availability of the
LEAST available component in the request path

one un-redundant component undoes redundancy
everywhere else in the design

Walk the full request path and name every single point of failure explicitly — an availability claim is only as strong as its least redundant component.

Spotted a mistake on this page? Tell us.

Read Sheet