Core System Design Properties

The "fantastic four" of system design are usually scalability, availability, reliability, and performance. These four properties appear in almost every architecture discussion because they describe different ways a system can succeed or fail under real use. They overlap, but they are not interchangeable, and confusing them leads to poor tradeoffs.

Scalability is the ability of a system to handle growth without a complete redesign. The growth might be in users, requests, data volume, or organisational complexity. A scalable system can add capacity or distribute work as demand rises. That does not mean it scales infinitely. It means the cost and complexity of growth are understood and reasonably controlled.

Availability is the proportion of time the system can serve requests successfully. A system may be highly available if it keeps responding during instance failures, deployments, and regional incidents. Availability is about being up and reachable from the user's perspective, even if some non critical features are degraded.

Reliability is about consistent correctness over time. A reliable system does not just respond. It responds with the right behaviour, preserves data accurately, and recovers predictably from faults. A service that returns fast but incorrect balances is available and performant in a superficial sense, but it is not reliable.

Performance concerns how efficiently the system does its work. Latency, throughput, resource use, and tail behaviour all sit here. Performance is often the property users feel first because they experience slow pages and lag directly, but chasing raw speed without the other three properties often produces brittle systems.

The interesting part is the tension between them. Replicating data across regions can improve availability, but it may complicate reliability if writes conflict or consistency weakens. Aggressive caching can improve performance and apparent scalability, but it may introduce stale data that harms correctness. A design that is beautifully reliable under one server may not scale operationally because every change requires manual coordination.

This is why system design is largely about choosing which failure modes are acceptable. Financial systems may trade some performance for stronger reliability guarantees. Consumer media products may accept stale recommendations if it improves scalability and cost efficiency. Internal tools may tolerate lower availability if that keeps the design much simpler.

The four properties are most useful when turned into explicit questions. How does the system behave when traffic doubles? What happens during a node failure? Which operations must never be lost or duplicated? What latency matters to the user, and at what percentile? Those questions force architecture discussions out of vague aspiration and into measurable design.

So the fantastic four are not a checklist to maximise independently. They are the main axes along which real systems are designed and judged. Good architectures do not "win" all four completely. They make the tradeoffs visible, align them with the product's needs, and build mechanisms that fail in the least damaging way when one property has to yield to another.