System Design, Performance, and Reliability
System Design, Performance, and Reliability tests whether you can turn requirements into a resilient architecture and reason about availability, capacity, and failure. Expect redundancy math, storage trade-offs, and bottleneck analysis.
Core concepts
Availability is uptime divided by total time; 99.9% allows about 8.76 hours of downtime per year. Serial components multiply availability, so adding dependencies reduces it. Redundancy in parallel improves availability if failures are independent: 1 − (1 − A)^n. RAID improves availability or performance but is not a backup. Load balancers distribute traffic; caches reduce latency but introduce invalidation problems; queues absorb bursts and decouple producers from consumers. CAP states that a distributed system facing a partition must choose consistency or availability.
Worked example
Two serial components each have availability 0.99. Combined availability is 0.99 × 0.99 = 0.9801, or 98.01%. If each component is duplicated in parallel with independent failures, each pair has availability 1 − (1 − 0.99)^2 = 0.9999. The serial pair then has 0.9999 × 0.9999 ≈ 0.9998, about 99.98%. Independence is an assumption, not a fact.
Traps
RAID is not a backup: it does not protect against deletion, corruption, or site loss. Availability multiplication assumes independence; shared power or network failures break that assumption. Throughput and latency are different metrics. Adding a cache can make stale data visible unless invalidation is designed.