Reliability vs Availability

The Definitions That Matter

 AVAILABILITY: is the service UP right now? (or: what fraction
              of time/requests does it respond?)
              
              uptime / total time = 99.9% availability

 RELIABILITY: does it do its JOB CORRECTLY over time?
              includes correctness, consistency, durability —
              not just "responded with something."

 the gap in one example:
   API returns 200 with WRONG BALANCE 100% of the time
   → availability 100%, reliability zero.

The Measurement Split

 AVAILABILITY counts:
 □ successful responses / total requests (request-based — better)
 □ uptime minutes / wall clock (time-based — crude)

 RELIABILITY adds dimensions:
 □ correctness rate (right answers)
 □ durability (data written stays written)
 □ consistency SLAs (read-your-writes held?)
 □ MTBF/MTTR-style longevity stats

 SLOs formalize both (own lessons):
   availability SLO: 99.9% of requests < 300ms, non-error
   reliability SLO:  99.99% of balance reads match ledger

Why Systems Sacrifice One for the Other

 classic tension — you often CHOOSE which to break:

 fail-stop design (AP-leaning):
   dependency down → return errors FAST
   → availability of the FUNCTION drops,
     but no wrong data → reliability preserved ✓

 degrade-and-continue:
   serve stale cache when DB down
   → availability preserved ✓, correctness risk taken

 neither is wrong — the CHOICE must be explicit per feature:
 payments: reliability always wins (no stale money!)
 feeds/rankings: availability usually wins (stale ok)

Building Blocks Per Goal

Goal	Primary levers
Availability	redundancy, failover, load balancing, graceful degradation
Reliability	idempotency, transactions, verification/reconciliation, chaos testing
Both	SLOs + error budgets driving priorities

 note the asymmetry:
 availability fails LOUDLY (pages fire immediately).
 reliability fails SILENTLY (wrong data discovered weeks later).
 silent failures need RECONCILIATION machinery to catch —
 budget for it explicitly.

Interview Framing

“Design a reliable payment system” scored instinct: define terms precisely first (“reliable = correct + durable; available = responding”), then choose the tradeoff stance explicitly (“payments prefer failing closed over wrong answers”), map levers accordingly. Interviewers use these words loosely too — defining them crisply mid-design is free credibility.