We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Core Fundamentals
The percentage of time a system is operational and accessible. Measured in 'nines', 99.99% availability means about 52 minutes of downtime per year.
In short
Availability is the percentage of time a system is up and able to serve requests. It is usually written in "nines": 99.9% allows about 8.8 hours of downtime per year, 99.99% allows about 52 minutes, and 99.999% allows about 5 minutes.
In short
Availability is the percentage of time a system is up and able to serve requests. It is usually written in "nines": 99.9% allows about 8.8 hours of downtime per year, 99.99% allows about 52 minutes, and 99.999% allows about 5 minutes.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Availability across a run of lessons, not one page. These 4 alone are about 104 minutes of step-by-step reading, every one with a quiz.
Design systems for maximum uptime, eliminate single points of failure across every layer.
Measuring how reliably your system serves requests, the nines that define your reputation.
Consistency, Availability, Partition Tolerance, you can only pick two, and you must pick partition tolerance.
Store writes temporarily on behalf of unavailable nodes. Dynamo's approach to write availability.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with High Availabilitypay once,
yours for life
Availability is the fraction of time a system is operational and reachable by its users, expressed as a percentage. If a service is up for 999 out of every 1000 minutes, it has 99.9% availability. People talk about it in "nines" because each extra nine is roughly a 10x reduction in allowed downtime, and each one is dramatically harder and more expensive to reach.
The math is simple. Availability equals uptime divided by total time. Over a 365 day year that is 525,600 minutes. So 99% lets you be down for about 3.65 days, 99.9% for about 8.77 hours, 99.99% for about 52.6 minutes, and 99.999% ("five nines") for about 5.26 minutes. A cloud provider's SLA of 99.95% means they promise no more than about 4.4 hours of downtime per year, or they owe you service credits.
Availability is not the same as reliability or durability. Reliability is about whether the system behaves correctly when it is up. Durability is about whether your stored data survives. A database can be 99.999% durable (it almost never loses data) but only 99.9% available (it sometimes refuses connections during a failover).
The core lever is removing single points of failure through redundancy. Instead of one web server you run several behind a load balancer, so one crashing does not take the site down. Instead of one database you keep a replica that can be promoted if the primary dies. The system stays available as long as at least one healthy copy of each component exists.
Redundancy only helps if failures are detected fast and traffic is rerouted automatically. Health checks ping each instance every few seconds, and the load balancer stops sending traffic to anything that fails them. Failover promotes a standby to take over a dead primary. The time this takes, often called recovery time, directly eats into your availability budget.
There is a useful rule for combining components. When parts are in series, meaning all of them must work, you multiply their availabilities, so two 99.9% services chained together give only 99.8%. When parts are redundant, meaning any one is enough, the combined system is far more available than either alone. This is why a system with many dependencies needs each one to be very reliable, and why teams spread copies across separate availability zones and regions so one data center outage cannot take everything down.
More availability is not free, and chasing nines you do not need wastes money and engineering time. The right target comes from the business. A payment system or hospital records system may justify five nines. An internal analytics dashboard is fine at three nines. The CAP theorem also forces a choice: during a network partition you can keep serving requests (stay available) or refuse them to stay strongly consistent, but not both.
Each extra nine roughly multiplies cost. Going from 99.9% to 99.99% often means multi-region deployment, automated failover, on-call rotations, chaos testing, and far more operational discipline. Going to five nines can mean active-active across regions with no manual steps anywhere in the recovery path, because even a few minutes of human reaction time blows the budget.
Most outages are not caused by hardware. They come from bad deploys, configuration mistakes, and dependency failures. So beyond redundancy, real availability work includes gradual rollouts, fast rollback, circuit breakers, rate limiting, and graceful degradation where the system serves a reduced experience instead of failing completely.
Consider an online store running in AWS. A single EC2 instance running both the app and the database might give you 99% availability, which is about 3.65 days of downtime a year and unacceptable for a shop.
Now spread it out. Run the app on three instances across three availability zones behind an Application Load Balancer, and use a managed database like RDS with a standby in a second zone for automatic failover. A single instance crash is invisible to customers because the load balancer reroutes traffic in seconds, and a database failure promotes the standby in a minute or two. This setup commonly reaches 99.95% to 99.99%.
If the business then needs to survive an entire AWS region going down, you replicate the whole stack into a second region with DNS-based or global load balancing that shifts traffic when the primary region fails health checks. That added complexity is what buys the jump toward five nines, and it is only worth it if a regional outage would genuinely cost more than the engineering and infrastructure it takes to defend against one.
Amazon Web Services
Publishes per-service SLAs such as 99.99% for EC2 across multiple availability zones and 99.999% for DynamoDB global tables, and pays service credits when it misses them.
Cloudflare
Runs an anycast network across hundreds of cities so a failed data center is simply routed around, keeping its DNS and CDN highly available.
Pioneered SRE practice built around error budgets, where the allowed downtime from an availability target is treated as a spendable resource that gates risky releases.
Netflix
Built Chaos Monkey to randomly kill production instances, proving the system stays available under failure rather than just hoping it will.
99.9% (three nines) allows about 8.77 hours of downtime per year, while 99.99% (four nines) allows only about 52.6 minutes. Each added nine cuts allowed downtime by roughly 10x and usually requires multi-zone redundancy and automated failover.
Availability equals uptime divided by total time, expressed as a percentage. For a year, total time is 525,600 minutes, so 99.99% availability means the system can be down for no more than about 52.6 of those minutes.
No. Availability is whether the system is up and reachable. Reliability is whether it behaves correctly when it is up. A service can be highly available but unreliable if it responds to every request with wrong results.
Five nines (99.999%) allows only about 5.26 minutes of downtime per year, which is less time than a human can react and fix something. It forces fully automated failover, active-active multi-region deployment, and removal of every manual step from the recovery path.
Only if they are truly redundant and failure is detected and rerouted automatically. If components are in series and all must work, adding more of them lowers combined availability because you multiply each part's availability together.
Availability Metrics
Measuring how reliably your system serves requests, the nines that define your reputation
CAP Theorem
Consistency, Availability, Partition Tolerance, you can only pick two, and you must pick partition tolerance
Hinted Handoff
Store writes temporarily on behalf of unavailable nodes. Dynamo's approach to write availability
Sloppy Quorum
Relaxed quorum rules that prioritize availability over strict replica placement
Zero-Downtime Deployment
Deploying new versions without any period of unavailability for users
Fault Tolerance
A system's ability to keep operating correctly even when some of its components fail. Achieved through redundancy, replication, and graceful degradation.
CAP Theorem
When a network failure splits a distributed data store, each node must either refuse requests to stay consistent or keep answering with possibly stale data. It cannot guarantee both during the partition.
Redundancy
Duplicating critical components or functions so that if one fails, a backup takes over. The reason planes have two engines and databases have replicas.
Latency
The time delay between sending a request and getting a response. Amazon found every 100ms of extra latency costs 1% in sales.
Throughput
The number of operations a system can handle per unit of time. Think of it as how many cars a highway can move per hour.
Bandwidth
The maximum amount of data that can be transferred over a network in a given time. It's the width of the pipe, not how fast the water flows.
This page explains the idea. The "High Availability" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the High Availability lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Availability in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
