01 What it is

Availability is the fraction of time a system successfully serves requests, measured against a defined threshold for success, usually a response within some latency budget and without a 5xx. It's normally expressed as a percentage of uptime over a period. "Three nines" means 99.9%, which allows about 8.76 hours of downtime a year. Flip it around and it's an error budget: the amount of failure you're allowed before you've broken the number you promised.

Availability is orthogonal to correctness and durability. A system that returns the wrong answer instantly is available and wrong. A system that hasn't lost a byte of data but can't currently serve a request is unavailable and correct. The number describes whether the system responds, not whether the response is right.

02 Why it matters

A single instance, one database, one region: the moment that one thing goes down (a bad deploy, a hardware fault, a network partition), the entire system is unavailable, not degraded, unavailable, for every user, at once, until someone notices and fixes it. There's no partial functioning and no fallback, because there was only one path through in the first place. The failure isn't rare. It's just correlated: one underlying cause takes out 100% of your capacity because nothing about the design was redundant.

In Plain Terms

A coffee shop with exactly one barista is fully staffed and fully fragile at the same time: the moment that one person calls in sick, the shop closes for the day, no matter how well-stocked the shelves are. A coffee shop with three baristas on rotating shifts can lose any single one of them to a sick day and still open, because someone else can step behind the counter. The second shop isn't "available" because nobody on staff ever gets sick, they still do. It's available because one missing person doesn't shut the whole place down.

03 How it works

Rendering diagram…

The mechanism is redundancy plus a way to detect and route around failure, not redundancy alone. Three instances behind a load balancer with no health checks is still a single point of failure, it just takes longer to notice.

04 Trade-offs

	Single instance	Redundant instances (N+1)
Failure blast radius	One fault takes down 100% of capacity	One fault takes down roughly 1/N of capacity, traffic reroutes to the rest
Cost	Cheapest option; exactly enough for the happy path	Extra idle capacity you're paying for so it's there when you need it
Operational complexity	Nothing to coordinate. One thing to deploy, one thing to monitor.	Needs health checks, a load balancer, and a deploy strategy that doesn't take every instance down at once
What it actually buys you	Nothing beyond raw compute	The ability to lose a machine, an AZ, or a bad deploy without losing the whole system

05 Where you'll actually see this

The URL shortener case study's cache-miss fallback is the same idea one layer down: when Redis is unavailable, the read path degrades to Postgres instead of failing outright. Slower, but still up.

Worth separating this from scalability: both lean on running multiple instances, but they're solving different problems. Redundancy here is about surviving a failure. Horizontal scaling is about handling more load. A fleet sized for one reason can end up looking identical to a fleet sized for the other, which is exactly why it's worth naming the difference instead of assuming "more instances" always means the same thing.

Database replication is this same redundancy idea applied to a database specifically, where the "instances" also have to agree, or explicitly not, on what the current data is. An app server behind a load balancer never has that problem, it's stateless. A database replica always does.

The error budget mentioned above in passing, the unused portion of "three nines," is more than a rounding of the percentage. SLIs, SLOs & error budgets is what that budget actually does in practice: a deliberately chosen target, not a number to always beat, and a real consequence, freezing feature work, once it's spent.

Worth being precise about where this redundancy logic stops applying, too. Disaster recovery looks like the same idea at a bigger scope, surviving a failure by having something else pick up the traffic, but it's a genuinely different problem once the failure is an entire region rather than one instance or one AZ. There's no automatic, seconds-long failover to route around a whole region going down, and the numbers that actually matter there, RPO and RTO, never come up in a conversation about one failed instance.

How to reason about it

When asked how you'd make a system highly available, don't just say "add more instances." Ask what failure you're actually protecting against and whether your redundancy is independent of it: three instances in the same rack or the same availability zone don't help if that rack or zone is what goes down. Naming the specific failure domain you're diversifying across is what separates a real answer from a buzzword.

06 Quick Check