Reason about latency and availability

Non-functional requirements are usually stated as latency and availability targets. To reason about them you need a feel for how long common operations take, how to describe latency honestly, and how combining components changes overall availability.

Rough latencies (orders of magnitude): main memory read ~100 ns; SSD random read ~100 µs; round trip within a data center ~0.5 ms; spinning-disk seek ~10 ms; round trip between continents ~100-150 ms. Memory is roughly 1,000× faster than SSD, which is why caches matter.

Percentiles: p50 is the median; p99 is the latency that 99% of requests beat. Averages hide the slow tail that real users feel.

Availability “nines”: 99.9% allows ~8.8 hours of downtime a year; 99.99% ~53 minutes; 99.999% ~5 minutes.

Combining components: if a request needs A and B (in series), availability is A × B, which is lower than either. If either of two replicas can serve (in parallel), availability is 1 − (1 − a)².

What each level allows per year: 99% is about 5,256 minutes of downtime, 99.9% about 526 minutes, and 99.99% about 53 minutes.

Each extra nine costs a lot more engineering: redundancy, automated failover, careful deploys. Teams make targets explicit with an SLI (what you measure, such as the fraction of successful requests), an SLO (the internal target, such as 99.9% over 30 days), and sometimes an SLA (a contract with customers that carries penalties).