Core Vocabulary & Quality Pillars
Why This Matters
Every HLD interview scores you against these four qualities, implicitly or explicitly. Naming which one you're prioritizing — and why — is the difference between a design that "just happens" and one that reads as deliberate.
Core Vocabulary
| Term | Definition |
|---|---|
| Throughput | Requests the system handles per second (QPS/RPS) |
| Latency | Time from request sent to response received — measure as p50/p95/p99, never a plain average (averages hide the tail that actually hurts users) |
| Availability | % of time the system responds successfully. 99.9% ("three nines") ≈ 8.7 hrs downtime/yr. 99.999% ("five nines") ≈ 5.3 min/yr |
| Reliability | System produces correct results even when parts fail — distinct from availability (a system can be up but returning wrong answers) |
| SLA | Service Level Agreement — external, often contractual, uptime/latency promise |
| SLO | Service Level Objective — internal target you engineer toward (usually stricter than the SLA, to leave margin) |
| SLI | Service Level Indicator — the actual measured metric (real p99 latency) you compare against the SLO |
The Four Quality Pillars
Scalability — handling growth
- Vertical scaling (scale up): bigger machine — more CPU/RAM/disk on one box. Simple, zero coordination overhead, but hits a hard physical ceiling and is itself a single point of failure.
- Horizontal scaling (scale out): more machines sharing the load. Where all internet-scale systems end up, but requires designing for statelessness and coordination from the start.
- Rule of thumb: start vertical (it's free — click a bigger instance), move to horizontal only when the numbers prove you've hit vertical's ceiling. Don't design for 1B users when the product has 10K.
Reliability — correct despite failure
- Disks fail, networks partition, processes crash — not edge cases, certainties over a long enough timeline.
- Achieved via replication (multiple copies), redundancy (no single instance load-bearing alone), and graceful degradation (partial functionality beats total outage).
- Goal: prevent failures from cascading into total collapse, not prevent all failure.
Availability — minimizing downtime
- Requires: no single points of failure, load balancers routing around unhealthy instances, fast failure detection + recovery.
- Trades off directly against consistency during a network partition — see [[CAP Theorem & Consistency Models]].
Maintainability — designed for change
- Can engineers who didn't build it understand, modify, and safely deploy changes a year later?
- Requires clear service boundaries, observability (logs/metrics/traces), modular architecture.
- Poor maintainability is the actual root cause behind most "let's rewrite from scratch" projects — worth naming if a design proposes something unusually clever/tightly-coupled.
Interview Drill
Q: A design has 99.99% availability but occasionally returns subtly wrong data during failover. Is it reliable? A: No — availability and reliability are separate axes. This system is available but not reliable. Naming this distinction unprompted is a strong signal.
Cross-links
[[CAP Theorem & Consistency Models]] · [[Latency vs Throughput]] · [[SD Interview Framework & Pitfalls]]