Designing an auto-scaling web tier

WHAT THIS TESTS The interviewer wants a coherent horizontal-scaling design and evidence you understand the supporting pieces, not just the phrase auto-scaling.

A GOOD ANSWER COVERS First make the application stateless by pushing session data to a shared store like Redis or a database, so any instance can serve any request. Place a load balancer in front to distribute traffic and run health checks. Define a launch template capturing the machine image, instance type, security groups, and bootstrap configuration, so every new node is identical. Create an auto-scaling group referencing that template, spanning at least two availability zones, with minimum, maximum, and desired capacity. Attach a scaling policy, preferring target-tracking, for example keep average CPU near fifty percent or maintain a request-per-target count, which adjusts capacity automatically. The group replaces unhealthy instances and adds or removes nodes as the metric moves.

COMMON WRONG ANSWERS Forgetting the load balancer, so new instances receive no traffic. Leaving the app stateful, so scaling loses sessions. Using only simple step or manual scaling for spiky load. Spanning a single AZ, sacrificing availability. Setting cooldowns so aggressively that scaling thrashes.

LIKELY FOLLOW-UPS How do you avoid thrashing during rapid fluctuations. Target-tracking versus step scaling versus scheduled scaling. How do health checks decide instance replacement. How do you handle scale-in safely without dropping in-flight requests through connection draining.

ONE CONCRETE EXAMPLE A news site fronts its app with an application load balancer, defines a launch template using a baked image, and creates an auto-scaling group across three AZs with min two and max twenty. A target-tracking policy holds average CPU near fifty percent. Sessions live in Redis, so when a story goes viral the group scales from two to twelve instances, the balancer drains connections on scale-in, and no user loses their session.