Phase 01 — System Design Fundamentals | Topic 11
Imagine your application is working perfectly.
Customers can log in.
Orders can be placed.
Payments are processed.
Then suddenly, one application server stops working.
What happens next?
If the entire application becomes unavailable, we have a design problem.
This is where Availability becomes an important part of System Design.
What Is Availability?
Availability describes the ability of a system to remain accessible and operational when users need it.
In simple words:
Availability means the system should continue serving users when possible, even when some components fail.
A system does not need to be available 100% of the time in every situation.
Instead, the business usually defines an expected availability level based on the importance of the application.
For example, a payment system may require much higher availability than an internal reporting application.
Why Does Availability Matter?
Users expect applications to be available when they need them.
Imagine a customer trying to place an order and receiving:
“Service unavailable.”
Even if the problem lasts only a few minutes, it can affect customer experience and business operations.
For critical systems, downtime can also cause:
Lost transactions
Lost revenue
Operational delays
Customer dissatisfaction
This is why availability should be considered during system design rather than only after deployment.
What Happens When a Component Goes Down?
Consider a very simple architecture:
Users
↓
Web Server
↓
Application Server
↓
DatabaseNow imagine the web server fails.
Users cannot reach the application even if the application server and database are still working.
This web server has become a Single Point of Failure.
What Is a Single Point of Failure?
A Single Point of Failure, or SPOF, is a component whose failure can cause the entire system or a critical part of it to become unavailable.
For example:
Users
↓
One Server
↓
Application
↓
DatabaseIf that one server fails, the system may become unavailable.
The problem is not that the server can fail.
Servers can fail.
The problem is that the architecture has no alternative path.
This leads to an important System Design principle:
Do not depend on a single component when its failure can stop the entire service.
How Do We Improve Availability?
One common approach is redundancy.
Instead of running one application server, we can run multiple instances.
For example:
┌── Application Server 1
Users → Load Balancer
└── Application Server 2Now, if one server fails, the other server may continue handling requests.
This is the basic idea behind designing systems that can tolerate individual component failures.
What Is Redundancy?
Redundancy means having additional instances or components available so that the system does not depend on only one resource.
For example, instead of:
One application server
we might have:
Two or more application servers.
Instead of relying on one critical component, we create alternatives.
Redundancy can be used at different levels of a system, including application servers, databases, network components, and other infrastructure.
The exact level of redundancy depends on the business requirements and the expected failure scenarios.
What Does a Load Balancer Do?
When multiple application servers exist, we need some way to distribute incoming requests.
A load balancer can sit in front of those servers and distribute traffic between them.
A simplified design looks like:
Users
↓
Load Balancer
↓
---------------------
↓ ↓
Server 1 Server 2If both servers are healthy, requests can be distributed between them.
If one server becomes unhealthy, the load balancer can stop sending new requests to that server, depending on the configured health-check and routing behavior.
This improves availability because the application does not depend on a single server.
What Is Failover?
Failover means moving processing to another available component when the primary component fails.
For example:
Primary Server
↓
Fails
↓
Backup Server
↓
Continues ServiceFailover can be automatic or manual depending on the system.
For important production systems, automatic failover is often preferred because it can reduce the time users are affected by a failure.
Health Checks Are Important
How does the system know that a component is unhealthy?
One common approach is a health check.
The application can expose an endpoint such as:
GET /healthThe platform or load balancer can periodically check that endpoint.
If the service is not healthy, traffic can be redirected away from that instance.
Health checks are therefore an important part of availability design.
Availability Is Not Only About Servers
Developers sometimes think:
“Just add multiple servers and the system is highly available.”
Not necessarily.
Imagine you have two application servers, but both depend on one database.
Load Balancer
/ \
Server 1 Server 2
\ /
DatabaseIf the database becomes unavailable, both application servers may still be unable to process requests.
The database has now become a potential Single Point of Failure.
This is why availability needs to be considered across the whole system, not just one layer.
A Practical Example
Suppose you are designing an e-commerce application.
A basic design may look like:
Users
↓
Single Application Server
↓
Single DatabaseThis is simple, but there are clear failure points.
A more resilient design could use:
┌── Application Server 1
Users → Load Balancer
└── Application Server 2
↓
Highly Available
DatabaseNow the system has more than one application instance, and the database can also be designed with appropriate redundancy depending on the chosen database platform.
The architecture is more complex, but that complexity exists for a reason: reducing the impact of failures.
Availability vs “Nothing Will Fail”
A common misunderstanding is:
“A highly available system never fails.”
That is not realistic.
Components can fail.
Networks can fail.
Databases can become unavailable.
External services can stop responding.
The goal of availability is not to prevent every failure.
The goal is to reduce the impact of failures and keep the service available whenever possible.
This is a much more practical way to think about production systems.
How Should You Think About Availability?
When designing a system, ask:
What happens if this component stops working?
Then continue:
Is there another component that can take over?
And:
How will the system detect the failure?
And finally:
How quickly can the system recover?
These questions naturally lead to design decisions involving:
Redundancy
Load balancing
Health checks
Failover
Monitoring
Alerts
Backup strategies
The exact solution depends on the system's requirements and constraints.
IMPORTANT Takeaway
A production system should be designed with the possibility of failure in mind.
Do not assume:
“This server will always be available.”
Instead, ask:
“What happens when this server goes down?”
That one question can reveal Single Points of Failure and lead to better architecture.
A simple way to remember it is:
Availability is not about preventing every failure.
It is about keeping the system usable when failures happen.
Final Thoughts
When you design an application, it is easy to focus on features and happy-path scenarios.
System Design asks us to think about something else:
What happens when something goes wrong?
If one server fails, can another handle the traffic?
If a database becomes unavailable, what happens to the application?
If an instance becomes unhealthy, can the system detect it?
The answers to these questions shape the availability of the system.
That is why availability should be considered from the beginning of the architecture, not after the first production failure.
What's Next?
We now understand availability and how redundancy helps reduce the impact of failures.
But availability and reliability are related concepts, and they are not exactly the same.
Phase 01 — System Design Fundamentals | Topic 12 — Reliability vs Availability
We will understand the difference between these two concepts using simple real-world examples.
Join the conversation! Your thoughts help the community grow.