Series: Building a Web App: A Beginner's Guide to Cloud Architecture (Part 1 of 5)
In this 5-part series, we are building a cloud-based application designed to handle high-stakes user registrations and critical data submissions. We will explore how to make it reliable, scalable, secure, and cost-effective using AWS and Azure.
The Story: A Server Goes Down
Imagine your application is processing user registrations for a massive event with a strict midnight deadline. Thousands of people are filling out their forms and submitting their details at the same time.
At 11:30 PM, the physical computer running the application experiences a hardware fault and turns off.
The website throws an error, form submissions stop working, and users are left stranded. For any business critical application, this kind of downtime is unacceptable.
So, how do we make sure our application stays online even when hardware breaks?
The Problem: The Single Point of Failure (SPOF)
When building a new app, most people start with the simplest setup: one virtual server running the website and the database together.
Pros - This is cheap and quick.
Cons - It creates a Single Point of Failure (SPOF). If that single server crashes, loses power, or loses its internet connection, everything stops working until someone manually logs in and restarts it.
The Solution: Don't Put All Your Eggs in One Basket
In cloud computing, we assume hardware will fail eventually. Instead of hoping a server never breaks, we design the system to automatically recover when it does. This concept is called High Availability (HA).
To achieve this, we use two fundamental building blocks:
- Availability Zones (AZs): Cloud providers group their physical data centers into regions. Inside each region, there are multiple, physically isolated data centers called Availability Zones. They have completely separate power supplies, cooling systems, and internet connections. If one building loses power, the other buildings keep running.
- A Load Balancer: Think of a load balancer like a traffic officer. It sits in front of your servers, constantly checks which ones are healthy, and directs incoming traffic only to the servers that are working properly.
How Does the Load Balancer Know a Server is Dead?
You might be wondering how exactly does the load balancer know when to stop sending traffic to Zone A and switch to Zone B?
It relies on a mechanism called a Health Check.
Think of the load balancer as an overly attentive manager checking in on its employees. Every few seconds, the load balancer sends a tiny, automated request (like a digital "ping") to every web server it manages.
- The Healthy State: If the server is working properly, it instantly replies with a success code (specifically, an HTTP 200 OK status). The load balancer logs this as a healthy heartbeat and continues sending users to that server.
- The Unhealthy State: If a server crashes, freezes, or loses power, it won't reply. If the load balancer misses consecutive heartbeats (for example, 3 failed checks in a row), it officially marks that server as Unhealthy.
Once a server is marked unhealthy, the load balancer instantly removes it from the rotation. New users are seamlessly routed only to the healthy servers remaining in the other Availability Zones. Once the broken server is fixed and starts replying to heartbeats again, the load balancer automatically adds it back into the mix.
Now that you know how load balancer works, lets build the Architecture diagram.
AWS Architecture Diagram
Azure Architecture Diagram
Now what happens when someone visits the application:
- The Load Balancer receives the request and sends it to either Web Server 1 or Web Server 2.
- If Web Server 1 crashes, the load balancer detects the issue immediately and routes 100% of user traffic to Web Server 2. The user doesn't notice any disruption.
- For the Database, our primary database continuously syncs all saved data to a standby database in Zone B. If the primary database fails, the cloud provider automatically switches to the standby copy without losing any user records.
AWS vs. Azure: Service Comparison
Both major cloud providers give you managed tools to set this up with just a few clicks:
| Component | What It Does? | AWS Service | Azure Service |
|---|---|---|---|
| Traffic Router | Directs web traffic to healthy servers | Application Load Balancer (ALB) | Azure Application Gateway |
| App Servers | Runs the application code across multiple zones | EC2 (in an Auto Scaling Group) | Virtual Machine Scale Sets (VMSS) |
| Database | Stores data with an automated backup copy | Amazon RDS (Multi-AZ) | Azure SQL (Zone-Redundant) |
Note: For regional High Availability in Microsoft Azure, use Azure Application Gateway. If you want to expand globally later, you would put Azure Front Door in front of everything.
Implementation: The One Line That Saves Your Data
When setting up infrastructure with code (using tools like Terraform), turn on high availability for a database.
Here is an AWS Terraform example:
resource "aws_db_instance" "my_application_db" {
allocated_storage = 50
engine = "postgres"
instance_class = "db.t3.medium"
db_name = "app_database"
username = "dbadmin"
password = var.db_password
# This single line tells AWS to automatically maintain a backup database in a second zone:
multi_az = true
}
By setting multi_az = true, AWS handles all the complex data replication, monitoring, and automatic failovers in the background.
Key Takeaway
High Availability isn't about buying invincible hardware. It is about deploying duplicate resources across different physical locations so a failure in one area doesn't take your entire platform down.
Further Reading & Official Documentation
If you want to dive deeper into the concepts covered in this article, check out the official documentation from AWS and Microsoft:
- AWS Well-Architected: Reliability Pillar
- Amazon RDS Multi-AZ Deployments
- Azure Well-Architected: Reliability
- Azure Application Gateway Zone Redundancy
Coming Up in Part 2: Now that our application won't crash from a single hardware failure, what happens when 50,000 users hit the site simultaneously on the final day of registration? We will cover Scalability and how to automatically add more power during traffic spikes.
Top comments (1)
Very helpful