Design a highly available web application

WHAT THIS TESTS This evaluates whether you can systematically remove single points of failure across every tier and let the system self-heal and scale.

A GOOD ANSWER COVERS Make the app tier stateless so any instance can serve any request, and run multiple instances across at least two availability zones. Put them behind a load balancer that performs health checks and routes only to healthy targets, draining failed ones. Wrap the instances in an auto-scaling group that replaces unhealthy nodes and scales on CPU or request count. Externalize state: store sessions in a shared cache like Redis and run the database in multi-AZ mode with a synchronous standby for failover plus read replicas for scale. Serve static content from a CDN. For the strictest availability, deploy to multiple regions with health-based DNS failover, accepting added cost and data-replication complexity.

COMMON WRONG ANSWERS A single big instance, vertical scaling only. Everything in one availability zone. No health checks, so traffic hits dead instances. Stateful app servers that break when an instance dies. A single primary database with no replica.

LIKELY FOLLOW-UPS How do health checks drain bad nodes? Multi-AZ versus multi-region trade-offs? How do you handle database failover? Where does session state live?

ONE CONCRETE EXAMPLE On AWS, an Application Load Balancer spans two AZs and health-checks targets in an Auto Scaling group; sessions live in ElastiCache; data sits in a Multi-AZ RDS instance with read replicas; CloudFront fronts static assets. If an AZ fails, the load balancer stops routing there, the ASG launches replacements in the healthy AZ, and RDS fails over to its standby with minimal downtime.