Scalability, reliability, availability, and the tradeoff vocabulary

Every design meeting you will ever sit in is secretly the same meeting. Someone proposes a design, the room pushes on it from several directions, and a compromise emerges.

The directions never change. There are nine of them, and this lesson (deliberately, unusually, a vocabulary lesson) hands you the full set.

Engineers sometimes call these the system’s quality attributes, or its non-functional requirements: not what the product does, but how well it must do it.

Learn these nine words and you can follow any architecture argument on Earth.

What is scalability?

ScalabilityConcept · lights on your mapscalabilityThe growth question: does more traffic just mean more capacity, or does it mean starting over? A scalable system absorbs growth by adding machinery; an unscalable one answers it with a rewrite. Never yes-or-no, since nothing scales forever; the argument is whether the breaking point outlasts the product’s ambitions. is how well a system handles growth: more users, more data, more traffic.

A scalable design can grow its capacity without being redesigned, while an unscalable one works today but must be rebuilt at each new size.

When someone asks “will it scale?” they are asking: does growth break this design, or merely make it bigger?

Scalability is not a yes-or-no property. Every design scales to a point, and the practical question is whether that point sits comfortably beyond the growth the product actually expects.

What is reliability?

ReliabilityConcept · lights on your mapreliabilityCorrectness, sustained. The reliable system does the right thing every time, not just most times, and speed is no substitute (a fast wrong answer is still wrong). Not the same as availability: reliability is being right, availability being reachable. is whether the system does the correct thing, consistently.

A reliable coffee backend never loses an order, never charges a card twice, and never shows Erik someone else’s account.

Reliability is not speed. A system that answers instantly with the wrong number is fast and unreliable.

What is availability?

AvailabilityConcept · lights on your mapavailabilityPresence: the fraction of time the system answers at all, quoted in nines (99.9%, 99.99%). The nines are a budget of allowed downtime, and every extra nine shrinks that budget tenfold while multiplying the bill. Present is not the same as correct, which keeps this word distinct from reliability. is whether the system is up, reachable and answering, when users need it.

Engineers measure availability in nines: the percentage of time the system is up.

As a rule of thumb, each additional nine costs roughly ten times the engineering: more spare machinery, more automation, more of Module 8’s zones and regions.

Keep availability and reliability distinct because systems fail differently:

• Reliability is being correct. Availability is being present.
• A system can be up all year and occasionally wrong: available, unreliable.
• A system can be down every night and never wrong while up: reliable, not very available.

What is performance? Latency and throughput

PerformanceConcept · lights on your mapperformanceHow fast and how much: the umbrella term over latency (time per operation) and throughput (operations per unit of time). “We have a performance problem” means one or both of those numbers has gone bad. is the umbrella word for how fast a system is and how much it can do.

Underneath the umbrella sit the two numbers you will hear daily.

LatencyConcept · lights on your maplatencyThe wait for a single answer, clocked from the user’s side. Small numbers with big feelings: a hundred milliseconds passes unnoticed, two seconds at checkout feels broken. Module 4’s round-trip time and Module 8’s distance-is-delay, now one of the nine. is how long one operation takes, measured on the requester’s clock: tap → response.

Module 4 named this word when it split bandwidth from latency, and Module 8 made it physical. What is new is its seat among the nine, quoted in milliseconds and felt in user patience.

ThroughputConcept · lights on your mapthroughputVolume: how much work gets done per second or per minute. A design can multiply it without making any single request faster, and the two numbers fail independently, which is why engineers ask which one went bad. Users feel latency; capacity planning buys throughput. is how many operations per unit of time the system can handle: requests per second, orders per minute.

The two are different numbers, and a drive-through proves it.

Picture one fast lane. Each car is served in two minutes (good latency), but only thirty cars pass per hour (modest throughput). Now add nine more lanes, and throughput soars tenfold while each car’s two minutes stays exactly the same.

Here is a preview for Module 13. Engineers rarely trust the average latency because averages hide the worst experiences, and they quote percentiles instead. “p99” means the time the slowest 1% of requests exceed. For now, this is recognition only.

What is security?

SecurityConcept · lights on your mapsecurityThe adversarial direction: how the design holds up when someone wants what they should not have. Its costs land on convenience and speed, which is why it loses quiet arguments until the week it wins them all. Met in pieces since Module 5; Module 14 gives it a throne. is the system’s resistance to misuse: who can get in, what they can reach, and what happens when someone hostile tries.

You have met security in pieces: never-trust-the-client in Module 5, tokens and keys in Module 6, secrets and firewalls in Modules 8 and 9. Module 14 assembles the pieces.

In design meetings, security is the direction that says “that convenient design opens a door,” and its price is usually paid in convenience and latency. Checks take time, and walls take work.

What is cost?

CostConcept · lights on your mapcostThe spend behind every design choice, in three currencies: cloud bills, third-party fees, and engineer hours, which usually dwarf the invoices. The other eight words are all purchased with this one, which is why cost wins so many arguments quietly. is what the design spends.

Cost arrives on three meters:

• Infrastructure: Module 8’s compute, storage, and networking bills
• Third parties: Module 5’s rented services, each with fees
• Engineer time: the meter beginners forget, and usually the most expensive one

Every box on the whiteboard is a meter running, and when someone says “that’s an expensive way to buy a millisecond,” cost is winning an argument against performance.

What is maintainability?

MaintainabilityConcept · lights on your mapmaintainabilityThe kindness a design shows to whoever inherits it. Weighted heaviest by people who have done the inheriting, since a system spends most of its life being changed by strangers. Module 11 prices the neglect as technical debt. is how easily future engineers can understand, change, and fix the system.

It is the least glamorous of the nine and the one veterans weight heaviest because they have been the engineer of two years from now, squinting at a clever design whose author has left the company.

Most of a system’s life is maintenance, and a brilliant optimization nobody can understand at 3am is not an asset. Module 11 gives this idea a memorable name: technical debt.

The load-bearing insight: they pull against each other

Here is what makes these nine words a vocabulary of arguments.

There is no design that maximizes all nine.

The tensions are structural:

• More availability usually raises cost: spare machinery, multiplied.
• Tighter security adds latency: every check takes time.
• The clever performance trick wounds maintainability.
• Building for massive scalability today runs up cost and complexity the product may never need.
• Shipping fast strains all of them at once, which is why deadlines make these meetings louder.

This is why it is always a meeting. The nine words are not a checklist to satisfy but directions to balance.

How to use the nine words

The skill you are building is not picking the “best” design because none exists.

The skill is twofold.

First, hear which words are in tension. “We could hit four nines, but we’d need three regions” is availability wrestling cost, and once you hear the words the argument’s shape is visible.

Second, ask which words this product actually needs. A payments system needs reliability and security at almost any cost. An internal lunch-ordering tool needs almost none of that, and the same design can be over-engineered for one product and negligent for another.

A useful principle is: designs are not right or wrong in general. They are right or wrong for a set of requirements.

When engineers ask “what are the requirements?”, this is what they are asking: which of the nine words matter here, and how much?

The mental model to remember

Scalability: does growth break the design, or merely enlarge it?

Reliability: is it correct, consistently? Availability: is it up, measured in nines?

Performance covers latency (the time of one operation) and throughput (the volume of many).

Security: resistance to misuse. Cost: infrastructure, third parties, and engineer time. Maintainability: can the engineers of two years from now change it safely?

The nine pull against each other, no design maximizes them all, and requirements decide which ones win.

You should now be able to sit in any design discussion, name the directions being argued from, and ask the question that resolves most of them: which of these does this product actually need?