Scalability, Availability, and Reliability

Beyond what a system does, design cares about how well it does it. Scalability, availability, and reliability are the key non-functional requirements.

Scalability is a system’s ability to handle growing load by adding resources — without falling over as demand climbs.

Vertical scaling (scaling up) means giving one machine more CPU, RAM, or disk. It is simple, but you eventually hit a hardware ceiling.

Horizontal scaling (scaling out) means adding more machines and spreading load across them. It scales much further, but demands stateless design.

Availability is the percentage of time your system is up and serving. It is usually quoted in "nines" — see how fast the allowed downtime shrinks.

Availability comes from redundancy: duplicate servers, multiple data centers, and automatic failover so a single failure never takes everything down.

Reliability is the probability a system runs correctly over time. An available system can still be unreliable if it responds but returns wrong results.

The distinction: available means it responds; reliable means it responds correctly, every time. Reliable usually implies available, but not the reverse.

A single point of failure is any component whose failure stops the whole system. Good design hunts these down and removes them with redundancy.

More availability and scalability mean more cost and complexity. Teams trade off these qualities against budget and what the system actually needs.

You turn these goals into numbers with SLAs (Service Level Agreements), tracked via SLOs and SLIs — making "reliable" a concrete, measurable target.

Test your understanding of these qualities.

You learned the core qualities: scalability (vertical vs horizontal), availability via redundancy, and reliability — kill single points of failure, measure with SLAs.