What Is System Design? Reliability, Availability, Scalability & Maintainability
The discipline of deciding how services, databases, and the connections between them hold up once real traffic shows up.
Beginner
TopNotchNote
Notes that matter
what system design actually means
Writing code that works on your laptop and writing code that keeps working when a million people hit it at once are almost different disciplines. System design is the second one: the practice of deciding how the pieces of a large, networked application — its services, databases, caches, queues, and the connections between them — fit together so the whole thing meets a set of requirements at scale, not just in a demo.
It draws on three underlying fields — computer networking (how machines talk to each other), parallel computing (how work is split across many processors), and distributed systems (how independent machines cooperate despite failures and delays) — and applies them to a concrete, practical question: given this many users, this much data, and this budget, what should the architecture actually look like?
the four goals every design is judged against
Almost every system design conversation, whether it's a real architecture review or an interview, comes back to the same four qualities. A design that's strong on all four is rare — most of the interesting decisions in this track are about which of these to trade away, and when.
| Goal | What it means | What breaks without it |
|---|---|---|
| Reliability | The system keeps producing correct results even when parts of it fail. | A payment gets charged twice because a retry wasn't idempotent. |
| Availability | The system is reachable and responsive when a client asks it something. | A checkout page returns errors during a traffic spike instead of degrading gracefully. |
| Scalability | The system absorbs more load — more users, more data — without a redesign. | A database that was fine at 10K rows falls over at 10M. |
| Maintainability | Engineers can understand, fix, and extend the system without fear. | A one-line feature request takes three weeks because nobody trusts the codebase. |
reliability vs. availability — a distinction worth keeping straight
These two get confused constantly because they sound like synonyms, but they measure different things. Availability is the percentage of time a service is reachable at all, usually expressed in "nines" — 99% ("two nines") is about 3.65 days of downtime a year, while 99.99% ("four nines") is about 52 minutes. Reliability is about correctness under stress: does the service keep producing the right answer, not just an answer.
A system can be highly available and unreliable at the same time — imagine a search box that always responds instantly (high availability) but silently returns stale or wrong results half the time (low reliability). The two most common metrics for reliability are MTBF (mean time between failures) and MTTR (mean time to repair):
MTBF = (Total Elapsed Time − Total Downtime) / Number of Failures
MTTR = Total Repair Time / Number of Repairs
The engineering goal is usually stated as: push MTBF up (fail less often) and push MTTR down (recover faster when you do). A system with a high MTBF but a terrible MTTR — rare outages that take six hours to fix — can end up less available over a year than a system that fails more often but self-heals in seconds.
scalability: vertical vs. horizontal
Say a photo-sharing app called Snaplog starts on a single server handling a few hundred users. As it grows, there are two fundamentally different ways to give it more capacity.
| Approach | How it works | Ceiling |
|---|---|---|
| Vertical scaling ("scaling up") | Add more CPU, RAM, or faster disks to the existing machine. | Bounded by the biggest single machine money can buy — and that machine gets disproportionately expensive. |
| Horizontal scaling ("scaling out") | Add more machines and spread the load across them. | In principle unbounded, but it requires the software to be written so that state can be split or replicated across machines. |
Most large-scale systems lean on horizontal scaling wherever they can, precisely because it doesn't have a hard ceiling — but it's also why so much of this track (load balancers, sharding, consistent hashing, replication) exists. Splitting work across many machines is easy to say and hard to do correctly once those machines need to agree on shared state.
maintainability: the goal that's easiest to neglect
Reliability and scalability get attention because they cause visible outages. Maintainability quietly determines how fast the team can keep shipping six months from now, and it breaks down into three ideas:
Operability — how easy it is to keep the system running smoothly day to day, including under partial failure. Lucidity (simplicity) — how easy the codebase is to understand, independent of whether it currently works. Modifiability — how easily new, unforeseen requirements can be added without a rewrite.
A system that's reliable and scalable but unmaintainable eventually stops being either — every fix risks a new outage because nobody fully understands the interactions anymore.
abstraction: the tool that makes any of this possible
None of the above is manageable if every engineer has to reason about the entire distributed system at once. Abstraction is the practice of hiding details that a given piece of code doesn't need to know about, so people can build on top of a component without understanding its internals.
Two abstractions show up constantly in this track. A transaction hides the mess of concurrent reads and writes behind a simple contract: either everything in it succeeds, or none of it does. A remote procedure call (RPC) hides the fact that a "function call" is actually a request traveling over a network, complete with serialization, retries, and the possibility of failure — the caller just sees something that looks like calling a local function. Both exist for the same reason: so the person writing business logic doesn't have to re-derive the hard parts of distributed systems every time they call another service.