Scalability
Scalability is the ability of a system to grow in capacity to meet increasing demand without loss of performance. A system is scalable if adding resources (servers, storage) produces a proportional increase in throughput.
Horizontal scaling (scale out): add more machines. Cheap commodity servers, better fault tolerance (no single point of failure), but adds distributed systems complexity. Examples: web app servers, Cassandra, HDFS.
Vertical scaling (scale up): add more power (CPU, RAM) to existing machines. Simpler but has a hard upper limit and creates a single point of failure. Examples: MySQL primary, monolithic apps.
Scalability anti-pattern: a system that performs well at 1,000 users but degrades at 1M users likely has a bottleneck component (DB, in-memory cache, single-threaded queue) that is not scaled horizontally.
Reliability
Reliability is the probability that a system will produce correct output over a given time period. A reliable system continues to work correctly even when components fail.
Reliability is achieved through redundancy — eliminating every single point of failure: multiple app servers, replicated databases, redundant network paths. The cost is added complexity and resource expense.
Example: Amazon S3 guarantees 11 nines (99.999999999%) of durability — effectively zero data loss — by replicating each object across multiple availability zones using erasure coding.
Reliability vs Availability: a system can be highly available (always responding) but not reliable (returning incorrect results). A bank transaction system must be both — always available AND always correct.
Availability
Availability is the percentage of time a system is operational and accessible. Measured in "nines": 99% = 3.65 days downtime/year, 99.9% = 8.76 hours/year, 99.99% = 52.6 minutes/year, 99.999% = 5.26 minutes/year.
Availability is calculated for a system's critical path. Components in series: A_system = A1 × A2 (each component's unavailability stacks). Components in parallel (redundant): A_system = 1 - (1-A1)(1-A2) — even two 99% components in parallel achieve 99.99%.
High availability techniques: active-active (multiple live servers), active-passive (standby takes over on failure), health checks and auto-restart, circuit breakers (fail fast when dependency is down).
Efficiency — Latency and Throughput
Two key efficiency measures: Latency (response time of a single request) and Throughput (number of requests served per second). Both matter and often trade off.
Latency components: network RTT, processing time, queueing delay, storage access time. P50, P95, P99 percentile latencies matter more than averages — a P99 of 5 seconds means 1 in 100 users waits 5 seconds.
Throughput: for a web service, throughput = requests/sec. For a database, throughput = transactions/sec (TPS). Throughput bottlenecks: CPU, memory, network bandwidth, disk I/O. Removing bottlenecks (via caching, indexing, horizontal scaling) increases throughput.
Little's Law: throughput = concurrency / latency. Double concurrency (servers) → double throughput. Halve latency → double throughput.
Manageability (Serviceability)
A system is manageable if it is easy to operate, monitor, diagnose, update, and repair. Manageability reduces MTTR (mean time to repair) when failures occur.
Key practices: comprehensive logging and metrics (latency, error rates, queue depths), distributed tracing (trace a request across microservices), health check endpoints, self-healing (automatic restart on crash), feature flags (turn features on/off without deploy), runbooks (step-by-step operational playbooks).
In interviews, mention manageability when discussing monitoring and observability — it shows operational maturity. A system that is fast and reliable but impossible to debug in production is not production-ready.