Availability in System Design: A Beginner-to-Advanced Guide

Think about the last time you tried to book a train ticket the moment tickets opened or grab concert tickets the second they went live and the site just... didn't load. Or gave you a spinning wheel forever. Or showed "Something went wrong, please try again." That's not a bug someone forgot to fix. That's availability or rather, the lack of it showing up in the one place everyone actually notices: right in front of them, at the worst possible moment.

Availability is one of those system  design words that sounds obvious until you try to define it properly. Everyone agrees a system should be "up." Almost nobody agrees on what "up" means when you get specific about it up for whom, measured how, for how long and at what cost. This article walks through all of that, from the basics to the architecture patterns real companies use, with real incidents to show what happens when it goes wrong.

What Is Availability in System  Design? (The Simple Answer)

Availability is the percentage of time a system is actually working and able to respond to requests, out of the total time it's supposed to be working. If your app was supposed to be reachable all day and it was actually reachable for 23 hours out of 24, its availability for that day was roughly 95.8%.

That's it. That's the whole idea at its core. Everything else in this article is really just answering one follow-up question after another :- how do you measure this properly, how do you build systems that hit a high number and what does it actually cost you to do that.

The formula, if you want it in numbers:

Availability (%) = (Total Time − Downtime) / Total Time × 100

A Real-Life Analogy Before We Touch Any Tech

Picture two shops on the same street. Shop A is a small bakery that opens at 9 and closes at 6 and on three random days last month, the owner just didn't show up sick, stuck in traffic, whatever. Shop B is a 24-hour pharmacy that has never once had its shutters down, because there's always a backup pharmacist on call if the regular one can't make it.

Both shops "work." But if you needed medicine at 2 AM, only one of them was available when it mattered. That backup pharmacist is, in system design terms, redundancy. The fact that the pharmacy stays open even when one specific person can't make it that's the entire idea of high availability, before you've written a single line of code. Systems that are "highly available" are built the same way: assume something (a server, a  data center, a person) will fail at some point and make sure the whole thing keeps running anyway.

Availability vs. Reliability vs. Uptime These Are Not the Same Thing

These three terms are often used interchangeably in engineering discussions, but they describe different things. The distinction becomes especially important in system design interviews, where saying "the system has high uptime, so it is highly available" can reveal a misunderstanding of what availability actually means.

Uptime

Uptime is the amount of time a system or process has continuously been running since its last restart.

For example, a Linux server might report:

up 400 days

That tells you the machine has not been restarted for 400 days. It does not automatically tell you that users could successfully access the application during all those 400 days.

In practice, however, the word uptime is also commonly used to describe an availability percentage. You will frequently hear statements such as "the service provides 99.99% uptime." Technically, that is describing an availability target, but the terminology is so common that it has become standard industry language.

So when someone says "uptime," always look at the context. Are they talking about how long a process has been running, or are they talking about the percentage of time a service was available?

Availability

Availability measures how often a system is operational and able to successfully serve requests when users need it.

For example, a service with 99.9% availability is expected to be usable for roughly 99.9% of the measurement period, subject to the exact SLA definition and exclusions.

A system can have extremely high uptime and still have poor availability.

Imagine an API server that has been running continuously for 200 days without a restart. However, during those 200 days it frequently becomes overloaded, stops responding to requests, returns errors, or gets stuck for several minutes at a time.

The process never technically stopped running, so its raw uptime looks excellent. But from a user's perspective, the service was unavailable during those periods.

A simple way to think about it is:

Uptime asks: "Is the system running?" Availability asks: "Can users successfully use the system?"

Reliability

Reliability is the ability of a system to perform its intended function correctly and consistently over time without experiencing failures. Reliability is therefore more concerned with how frequently failures occur and how consistently the system behaves, rather than simply whether the system is currently responding.

For example, imagine an API that crashes once every two hours but automatically restarts within a few seconds. The service might still achieve a reasonably high availability percentage because each outage is short. However, the system is clearly not very reliable: it is repeatedly failing.

This distinction becomes particularly important in distributed systems. A service may be available most of the time while still having frequent database errors, message-processing failures, dropped connections, or intermittent incorrect behavior.

Availability and Reliability Can Move Independently

This is why availability and reliability should not be treated as synonyms.

A system that fails frequently but automatically recovers in milliseconds may have excellent availability but poor reliability. Conversely, a system that rarely fails but takes hours to recover from each failure may have good reliability but poor availability.

How This Relates to CAP Availability

There is one more distinction that matters for CAP theorem. CAP availability is not the same thing as the availability percentage used in SLAs. CAP uses a much stricter definition: every request sent to a non-failing node must eventually receive a response, even when the system is experiencing a network partition.

Suppose two database replicas lose communication:

          Network Partition
      X X X X X X X X X X X

   Mumbai DB             Singapore DB
      |                       |
   Request                  Request
      |                       |
      ↓                       ↓
  Can respond?             Can respond?

• A system that continues responding to requests on both sides is favoring CAP availability, even if some responses contain stale data.

• A system that refuses some requests until replicas can communicate again may sacrifice CAP availability in favor of consistency.

So there are really two different conversations happening:

• Operational availability: "What percentage of the time can users successfully use our service?"
• CAP availability: "During a network partition, does every request to a functioning node receive a response?"

Keeping these definitions separate makes CAP much easier to understand.

A Simple Way to Remember the Difference

Think of a clock:

• Uptime: the clock has been running continuously for 400 days.
• Availability: what percentage of the time could someone actually read the correct time from it?
• Reliability: how consistently does the clock continue working without failures?

And in CAP:

• Availability: if the network breaks between distributed nodes, will the system continue responding to requests?

A simple way to keep them straight: uptime tells you the clock hasn't stopped, reliability tells you how often the clock breaks and availability tells you what fraction of time someone could actually get an answer out of the system.

How Availability Is Actually Measured: SLA, SLO and SLI

When engineers talk about a service being "99.9% available," there needs to be a clear definition of what that percentage actually represents. Is it the percentage of successful requests? The percentage of time the server is reachable? Does a slow response count as available? What about a request that returns HTTP 500?

This is where SLI, SLO and SLA come into the picture. The three terms are closely related, but they answer three different questions: What happened? What do we want to achieve? And what have we promised our customers?

SLI (Service Level Indicator)

SLI is the actual metric used to measure a service's performance. For example, if we measure the percentage of valid API requests that complete successfully, the result might be:

99.96% of requests succeeded during the last 30 days.

Here, 99.96% is the measured SLI.

SLO (Service Level Objective)

SLO is the target we set for that SLI. For example:

At least 99.9% of valid API requests should succeed.

In this case, 99.9% is the SLO, while 99.96% is the actual measured SLI. The SLO tells the engineering team what level of service it aims to maintain.

SLA (Service Level Agreement)

SLA is the external commitment made to a customer, usually as part of a contract. It defines the expected service level and may specify consequences, such as service credits, if the commitment is not met.

A simple way to remember them is:

SLI → What are we measuring? SLO → What level do we want to achieve? SLA → What level have we promised externally?

For example:

One important point: SLI is not limited to availability. It can also measure latency, error rate, throughput, data freshness, or other characteristics that matter to users. The exact SLI depends on what aspect of the service you want to measure.

• The SLI is your actual score.
• The SLO is the score your team expects to achieve.
• The SLA is the score you have formally promised someone else.

That distinction becomes particularly useful in large distributed systems because "availability" is not simply a number you put on a dashboard. You first need to define what counts as a successful request, how it is measured, over what time window and what happens when the target is missed.

And this brings us back to CAP: CAP availability is a property of how a distributed system behaves during a network partition, while SLI/SLO/SLA are mechanisms for measuring, targeting and committing to service performance. They are related, but they are not interchangeable.

The "Nines" What 99.9% Availability Actually Means in Real Time

This is where a lot of the confusion clears up, because "99.9%" sounds impressively close to 100% until you convert it into actual hours and minutes.

Look at how steep that curve is. Going from 99% to 99.9% doesn't just shave off "a bit" of downtime. It cuts your allowed downtime for the entire year from almost four days down to under nine hours. Going from 99.9% to 99.99% takes you from "you could have a rough afternoon once a year" to "you basically can't have a single bad hour, ever." Each additional nine is not a small improvement; it's an order-of-magnitude jump in how little can go wrong and as we'll get to later the engineering cost usually scales the same way.

Why Downtime Happens: The Real Causes

Systems don't go down for one dramatic reason most of the time. It's usually one of these:

• Hardware failure a disk dies, a server's power supply fails, a network switch stops responding. Physical things break and at large enough scale, something is always breaking somewhere.

• Software bugs a memory leak that eventually crashes a service, a null pointer exception on an edge case nobody tested, a deadlock under specific timing conditions.

• Traffic spikes a system built to handle normal load buckles the moment something unusual happens: a flash sale, a viral post, a sudden surge that nobody provisioned for.

• Human error during deployment a config change pushed straight to production, a database migration that locks a table longer than expected, a command run against the wrong server. This one is far more common than people assume and we'll look at a very well-documented real example shortly.

• Network and DNS issues the servers can be perfectly healthy, but if nobody can route to them, they might as well be off.

• Security incidents a distributed denial-of-service (DDoS) attack floods a system with fake traffic until real users can't get through, even though nothing is technically "broken."

Real Incident #1: When One Command Took Down a Huge Slice of the Internet

On February 28, 2017, an Amazon Web Services engineer was debugging a slowdown in the S3 billing system and ran a command meant to remove a small number of servers from that subsystem. Due to incorrect input, the command removed far more servers than intended enough to also take offline two critical S3 subsystems: the index subsystem, which manages where every object is stored and the placement subsystem, which allocates storage for new objects. Because so much of the internet depends on S3 behind the scenes, a huge number of sites and services in the US-EAST-1 region either broke outright or degraded, including parts of AWS's own console and other services like EC2 and Lambda that depend on S3.

The outage lasted roughly four hours and seventeen minutes, according to AWS's own public post-event summary. What makes this incident genuinely useful to study isn't just "a person made a typo" it's what AWS changed afterward: they rebuilt the removal tool to work more gradually with built-in safety thresholds and restructured their internal systems so that a single mistake couldn't remove that much capacity that fast again. That's the real lesson about availability it's not just about redundant servers, it's about designing your own operational tools so a single human mistake can't cascade into a multi-hour outage.

Real Incident #2: When Facebook Disappeared for Everyone, Everywhere

On October 4, 2021, Facebook, Instagram and WhatsApp went down globally for around six hours. According to Meta's own engineering blog, it started with a routine maintenance command intended to check the availability of backbone network capacity between Facebook's data centers. A bug in the audit system that was supposed to catch exactly this kind of mistake failed to stop it and the command instead took down all the connections in Facebook's backbone network the internal network that links its data centers to each other and to the rest of the internet.

Here's the part that makes this incident a genuinely great teaching example: that internal backbone failure triggered a second, external failure. Facebook's DNS servers are designed to withdraw their BGP (Border Gateway Protocol the routing system that tells the internet how to reach a given network) advertisements whenever they can't reach the data centers, as a safety measure against advertising routes to a network that isn't actually working. With the backbone down, the DNS servers did exactly what they were designed to do and withdrew those routes which meant the rest of the internet could no longer find a path to Facebook's DNS servers at all, even though the servers themselves were still technically running. Worse, many of Facebook's own internal tools relied on that same DNS infrastructure, so the very tools engineers needed to diagnose and fix the problem were themselves unreachable. Engineers reportedly had to be physically dispatched to data centers to fix things by hand and the facilities' own high physical security normally a good thing slowed down emergency access.

The lesson here goes beyond "have backups." It's that your monitoring, alerting and recovery tools need to be independent of the very system they're meant to rescue if your incident response tooling goes down along with the incident, you've lost your ability to respond at exactly the moment you need it most.

Real Incident #3: When a DDoS Attack on One Company Took Down Half the Internet's Big Names

On October 21, 2016, a massive DDoS attack hit Dyn, a company that provided DNS services for a long list of major websites. The attack used the Mirai botnet malware that had infected huge numbers of ordinary IoT devices like home security cameras and routers, turning them into an army of machines flooding Dyn's servers with junk traffic. Because so many major sites relied on Dyn for DNS resolution, the attack effectively took down access to Twitter, Netflix, Reddit, Spotify and several other well-known services for large parts of the day, even though none of those companies' own servers were ever actually attacked.

This incident is a genuinely important one for understanding availability, because it shows that your system's availability isn't only about your own infrastructure it's about every dependency in the chain, including ones you don't control at all, like your DNS provider. A system can be perfectly engineered and still go dark because a critical dependency three layers away got flooded with traffic that had nothing to do with you.

How Systems Actually Achieve High Availability

Now for the part that actually builds things. These are the real techniques behind every "highly available" system you've ever used.

1. Redundancy: No Single Point of Failure

The core idea is simple don't let any one component's failure take down the whole system. If one server can fail, run at least two. If one data center can lose power, spread across more than one. This sounds obvious and it is, but it's astonishing how often real outages trace back to exactly one thing that nobody redundant because "it probably won't fail."

2. Load Balancing

A load balancer sits in front of multiple servers and spreads incoming traffic across them. If one server goes unhealthy, the load balancer stops sending it traffic and routes everything to the healthy ones the user never notices that one machine quietly dropped out of the pool.

3. Failover: Active-Passive vs. Active-Active

There are two broad patterns for how a backup system takes over when the primary fails.

ACTIVE-PASSIVE (Primary / Standby)

        All traffic
            |
            v
     +--------------+          +--------------+
     |   PRIMARY    |          |   STANDBY    |
     | (handling    |  synced  | (idle, ready |
     |  all traffic)|--------->|  to take over)|
     +--------------+          +--------------+
                                      ^
                        if primary dies, traffic
                        fails over here (some delay)

--------------------------------------------------------------

ACTIVE-ACTIVE (Both Nodes Serving Traffic)

                     Load Balancer
                    /             \
                   v               v
          +--------------+  +--------------+
          |   NODE A     |  |   NODE B     |
          | (serving     |  | (serving     |
          |  traffic)    |  |  traffic)    |
          +--------------+  +--------------+
                   \               /
                    v             v
                 Shared / replicated data store

  If Node A dies, Node B was ALREADY serving live traffic --
  the load balancer just stops sending requests to A. No failover
  delay for traffic that lands on Node B. Whether this needs any
  extra conflict-handling logic depends entirely on what's behind
  these nodes (see below).

Active-passive is simpler to reason about the standby is just sitting there doing nothing until it's needed but there's usually a short gap while the system detects the failure and switches over, during which requests can fail. Active-active removes that gap, since both nodes are already live and already absorbing traffic.

It's worth being precise about what active-active actually implies, because it's easy to over-generalize here. Most active-active setups you'll run into are at the stateless application or web tier both nodes are just running the same code and reading/writing through the same shared database behind them. In that case, active-active adds no conflict problem at all, because neither node is independently deciding what the "true" data is; they both defer to the same backend. The conflict-resolution problem only shows up when the data layer itself is deployed active-active for example, a multi-master database where two database nodes in different regions can each accept writes independently. That's a real and useful pattern (it's what lets each region write locally with low latency), but it's a specific, more advanced case, not something every active-active system needs to solve. And it's precisely in that specific case an active-active data layer, during a network partition between its nodes that you run into the exact consistency-versus-availability trade-off described by the CAP theorem, which we've covered in detail in our CAP Theorem in System Design guide.

4. Multi-AZ and Multi-Region Architecture

An Availability Zone (AZ) is typically one or more physically separate data centers within a region, with independent power, cooling and networking, so a failure in one doesn't take down the others. Spreading your servers and databases across multiple AZs protects you against a single data center having a bad day a power failure, a cooling system fault, a fiber cut.

A highly available web app spread across two data centers (AZs)

                                Users
                                  |
                                  v
                         +----------------------+
                         | DNS / Global         |
                         | Load Balancer        |
                         +----------------------+
                            /              \
                           v                v
     +----------------------+     +----------------------+
     | AVAILABILITY ZONE A  |     | AVAILABILITY ZONE B  |
     |                      |     |                      |
     | App Server 1         |     | App Server 3         |
     | App Server 2         |     | App Server 4         |
     | (behind local LB)    |     | (behind local LB)    |
     +----------------------+     +----------------------+
               |                            |
               v                            v
     +----------------------+     +----------------------+
     | Primary DB           |     | Replica DB           |
     | (read + write)       |     | (read-only, synced)  |
     +----------------------+     +----------------------+

  If Zone A goes down entirely (power, network, hardware): the load
  balancer routes all traffic to Zone B and the replica DB can be
  promoted to primary. No single zone failure takes the whole app down.

The diagram above shows one common pattern a single primary database with a synced replica standing by but it's worth knowing this isn't the only way databases handle multi-AZ or multi-region availability and the details matter. Some setups replicate synchronously, meaning a write isn't confirmed until the replica has it too safer against data loss on failover, but it adds latency to every write, since you're waiting on a round trip to the other zone. Others replicate asynchronously, which is faster for writes but means a handful of the most recent transactions can be lost if the primary fails before they've synced across this is exactly what an RPO (Recovery Point Objective, covered later in this article) is meant to quantify. And some databases don't use a single-primary model at all systems like DynamoDB global tables, Cassandra or CockroachDB support genuinely active-active, multi-master writes across regions, where more than one node can accept writes independently and the database itself handles reconciling them. Which model fits depends on how much write latency you can tolerate versus how much potential data loss or conflict-handling complexity you're willing to accept there's no single "correct" replication strategy that fits every system.

Multi-region takes this further spreading infrastructure across entirely different geographic regions, protecting against something that takes out an entire region (a regional network backbone issue, a natural disaster, a regional cloud provider outage like the AWS S3 incident above). It's a bigger jump in cost and complexity than multi-AZ, because data now has to travel much longer distances to stay in sync and that adds latency you can't avoid which is exactly why most systems don't reach for multi-region until they genuinely need it.

5. Health Checks and Auto-Healing

A health check is a small, regular request a system sends to itself or its components "are you actually working?" often hitting a dedicated endpoint like /health. If a server stops responding correctly, it gets pulled out of rotation automatically and in cloud environments, a fresh replacement can be spun up without anyone needing to be paged at 3 AM. Kubernetes formalizes this with liveness probes (is the container still alive or does it need to be restarted?) and readiness probes (is the container ready to actually receive traffic yet?) a genuinely useful distinction, since a container can be alive but not yet ready, for instance while it's still loading data on startup.

6. Graceful Degradation and Circuit Breakers

Not every failure needs to become a total outage. Graceful degradation means designing a system so that when one part fails, the rest keeps working in a reduced way instead of falling over completely an e-commerce site whose recommendation engine goes down should still let people check out, just without "customers also bought" suggestions. A circuit breaker is the pattern that enforces this automatically: when calls to a dependent service start failing repeatedly, the circuit breaker "trips" and stops sending new requests to it for a while, failing fast with a fallback response instead of letting every request hang and time out, which would otherwise make things worse by tying up resources waiting on a service that's already struggling.

7. Rate Limiting and Overload Protection

Sometimes the threat to availability isn't a component breaking it's simply too much legitimate (or illegitimate) traffic arriving at once. Rate limiting caps how many requests a single client or API key can make in a given time window, protecting the system from being overwhelmed, whether that's a traffic spike, a buggy client retrying too aggressively or an actual DDoS attempt.

8. Chaos Engineering

Rather than waiting to find out if your redundancy actually works during a real outage, some teams deliberately break things on purpose, in a controlled way, to verify failover actually behaves as expected. Netflix popularized this with a tool called Chaos Monkey, which randomly terminates production instances during business hours specifically so engineers are forced to build systems that survive it, rather than discovering gaps in redundancy during an actual incident.

The Trade-Offs: Why Isn't Everything Built for Five Nines?

Because it's expensive and not every system needs it. Higher availability generally means more servers, more regions, more complex failover logic, more monitoring and more engineers maintaining all of it. Each additional "nine" tends to cost significantly more than the one before it the jump from 99% to 99.9% might mean adding a second server and a load balancer; the jump from 99.9% to 99.999% might mean multi-region infrastructure, dedicated on-call teams and constant failover testing.

There's also a real trade-off with consistency, which is where availability connects directly back to the CAP theorem. During a network partition, a system has to choose between staying available (possibly returning slightly stale data) or staying strictly consistent (possibly refusing some requests). Neither choice is free an internal analytics dashboard can usually tolerate a few stale seconds of data in exchange for never showing an error; a bank balance generally can't.

And there's a trade-off with latency too: spreading data across more regions to survive a regional failure means more network round-trips to keep everything in sync and that adds delay to every single request, whether or not anything ever actually fails.

When to Prioritize High Availability and When Not To

Push hard for high availability when downtime directly costs money, safety or trust in a very visible way payment systems, checkout flows, authentication services, anything customer-facing at scale. Push less hard when the cost genuinely isn't justified an internal reporting tool used by twelve people during business hours doesn't need multi-region failover and building it anyway is money and complexity spent on a problem that doesn't really exist for that system. A good system designer doesn't chase "maximum availability everywhere" they figure out which parts of a system actually need it and spend the engineering budget there instead of spreading it thin across everything equally.

Common Mistakes and Misconceptions About Availability

• Believing 100% availability is achievable. It isn't, not in any real system with real hardware and real networks. Every serious availability target even five nines accepts some amount of downtime as physically inevitable and it's usually stated explicitly for exactly that reason.

• Confusing "multiple servers" with "high availability." Running three servers in the same rack, in the same data center, on the same power circuit, isn't real redundancy it's one shared failure point wearing a disguise. Redundancy only counts if the backup can survive whatever takes out the primary.

• Assuming failover works without ever testing it. A standby database that's never actually been promoted to primary in a drill is a hope, not a plan. This is exactly the gap chaos engineering exists to close.

• Treating disaster recovery and high availability as the same thing. High availability is about minimizing downtime during common, smaller failures automatically and quickly. Disaster recovery is the broader plan for surviving a catastrophic event and it can involve real data loss and real, planned downtime, just a bounded and rehearsed amount of it, measured in two more terms worth knowing: RTO (Recovery Time Objective), how long you're willing to be down and RPO (Recovery Point Objective), how much data you're willing to lose, measured in time since the last good backup.

• Ignoring dependencies outside your own infrastructure. As the Dyn DNS incident shows, your availability is only as strong as the weakest external service you depend on a payment gateway, a DNS provider, a third-party API even when your own servers never go down at all.

Observability: How You Actually Know You're Available

You can't manage what you can't see. Real systems track availability through a mix of synthetic monitoring (automated requests sent to your own endpoints from outside, simulating a real user, on a schedule, from multiple locations), real user monitoring (measuring actual user requests and their success/failure rates) and alerting thresholds tied to your SLOs, so a team gets paged before customers start noticing, not after. Dashboards showing current error rates and response times matter, but the metric that actually reflects availability over time is the error budget how much of your allowed downtime (based on your SLO) you've already used up in the current period, which tells a team whether they can afford to ship a risky change this week or whether they need to slow down and stabilize first.

Frequently Asked Questions

1. What is a good availability percentage for a website?

It depends entirely on what the website does. A personal blog can live happily at 99% or even less. A payment processing system or a healthcare application usually targets 99.9% or higher, because the cost of downtime is measured in real money or real harm, not just inconvenience.

2. Is 100% uptime possible?

No, serious system claims this and for good reason hardware fails, networks have outages and even the biggest companies in the world have had multi-hour global outages, as the Facebook and AWS incidents in this article show. Every realistic availability target explicitly accounts for some amount of downtime.

3. What's the difference between availability and scalability?

Availability is about whether the system is up and responding at all. Scalability is about whether it can keep responding well as load increases. A system can be highly available at low traffic and completely fail to stay available the moment traffic spikes tenfold the two are related but not the same problem.

4. Does having a backup server automatically mean high availability?

Not by itself. It depends on where that backup lives, whether failover to it is automatic or manual, how long failover takes and whether it's actually been tested. A backup that's never been tested is a common source of false confidence.

5. What causes most real-world outages?

A large share trace back to human error during changes a bad deployment, a misconfigured command, an unintended side effect of a routine operation rather than pure hardware failure. Both the 2017 AWS S3 outage and the 2021 Facebook outage described above started with a command that didn't do what the person running it expected.

6. How is availability different from an SLA?

Availability is the actual measured percentage of uptime. An SLA is the promise usually contractual that a provider makes about what availability level customers can expect, often with penalties or credits attached if it isn't met.

7. Interview Perspective

Availability questions in system design interviews are rarely about reciting the "nines" table from memory they're about whether you can reason through trade-offs out loud. Common prompts include: "How would you design a highly available URL shortener / e-commerce checkout / chat application?" (a strong answer walks through redundancy, load balancing and what happens specifically when one component fails, not just a list of buzzwords). "What's the difference between availability and consistency and when would you choose one over the other?" (this is your opening to bring in CAP theorem naturally). "How would you design a system to detect an outage before customers report it?" (tests whether you think about observability, not just architecture). "Walk me through what happens, step by step, if a server in your design crashes right now." Interviewers are almost always more interested in your reasoning process how you weigh cost against risk and what you'd measure to know it's working than in a memorized "correct" architecture.

The Bottom Line

Availability isn't a single number you bolt onto a system at the end it's a series of deliberate decisions made throughout the design, from how many servers you run to how you handle the one that inevitably fails anyway. The real-world incidents in this article a mistyped command at AWS, a safety check that backfired at Facebook, a botnet flooding a DNS provider nobody outside the industry had heard of all share the same lesson: availability isn't just about your own servers staying up. It's about anticipating the specific ways things actually fail and building a system that keeps working anyway, even when you can't predict exactly which piece breaks first.

Related Articles

CAP Theorem in System Design: Consistency, Availability and Partition Tolerance Explained the deeper trade-off between availability and consistency that every highly available system eventually has to make.

Linux Commands in DevOps: The Complete Practical Guide the day-to-day commands used to monitor, diagnose and keep systems like the ones described here actually running.

Load Balancer in System Design: Complete Beginner to Advanced Guide

Latency vs Throughput in System Design

Throughput in System Design : The Complete Beginner to Advanced Guide

Latency in System Design: The Complete Beginner to Advanced Guide

Scalability in System Design: The Complete Beginner to Advanced Guide

How to Approach Any System Design Problem

Sources referenced:

Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region AWS

More details about the October 4 outage Engineering at Meta

DDoS on Dyn Impacts Twitter, Spotify, Reddit Krebs on Security