Highly Available Architecture Project
Part of the Cloud Computing Roadmap
In short
Saying "my app is highly available" is easy. Killing a server live while traffic keeps flowing, and showing the screen recording, is what makes an interviewer lean forward.
Design and deploy an architecture with genuine redundancy across availability zones, an auto scaling group, and a load balancer — then demonstrate it surviving a simulated instance failure.
Think of it like this
The twelfth man on the bench
A cricket team always has players ready on the bench. If a fielder gets hurt, a substitute runs on and the over continues. The crowd barely notices. HA means your app has its substitutes warmed up, on different benches.
Watch it happen
One availability zone loses a server
GET / (many users)
1/6Traffic arrives at the load balancer, which spreads it across two zones.
The big ideas
What you need to know
Two or more zones
Spread servers, subnets and the database across availability zones. One zone failing must not take you down.
Real health checks
A /health endpoint that checks the app actually works, so the load balancer routes around broken servers.
Database failover
Use a Multi-AZ managed database, so a standby takes over if the primary fails.
Prove it
Record a chaos test: a loop hitting the site while you terminate a server. Add it to your README.
See it in code
Walk through the code
1# 1. Keep hitting the site and print status codes2while true; do curl -s -o /dev/null -w "%{http_code}\n" "http://$ALB_DNS/"; sleep 1; done &3 4# 2. Pick one instance from the Auto Scaling group and kill it5ID=$(aws autoscaling describe-auto-scaling-groups \6 --auto-scaling-group-names web-asg \7 --query "AutoScalingGroups[0].Instances[0].InstanceId" --output text)8aws ec2 terminate-instances --instance-ids "$ID"9 10# 3. Watch targets drain and the replacement register11aws elbv2 describe-target-health --target-group-arn "$TG_ARN" \12 --query "TargetHealthDescriptions[].[Target.Id,TargetHealth.State]"1/3A background loop prints one status code per second, so you can see if users would notice.
Your chaos test. Expect a steady stream of 200s, maybe a brief blip, while one server dies and a new one appears.
Save yourself the pain
Common mistakes
Oops
Two servers in the same availability zone and calling it highly available.
Do this instead
Put them in different zones. A zone outage takes out everything inside it.
Oops
A health check that only returns 200 from the web server, even when the database is down.
Do this instead
Have /health check what the app needs, but keep it fast so checks don't overload anything.
Your mission
First milestone: survive one kill
Quick check
During your chaos test, who launches the replacement server?
Go deeper
- 1Deploy across at least 2 availability zones with an auto scaling group and load balancer.
- 2Simulate a failure (terminate an instance) and document how the system recovered.
- 3Include your RTO/RPO targets and how your architecture meets them.
More projects at this stop
Deploy a 3-Tier Web Application on AWS / Azure / GCP
Serverless API Project
Infrastructure as Code Project (Multi-Environment)
Cost-Optimized Migration Case Study
Monitoring & Alerting Setup Project
Portfolio Website or GitHub Showcase
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
