Right-sizing an Auto Scaling group for a flash sale
A retail team runs a web tier on Alibaba Cloud behind a Server Load Balancer (SLB). During normal hours, 4 ECS instances (ecs.g6.xlarge, 4 vCPU / 16 GiB) handle about 35% average CPU. Marketing announces a flash sale expected to bring 6x normal traffic for a 90-minute window. The team configures an Auto Scaling group with min=4, max=20, and a target-tracking rule at 60% average CPU. Ten minutes into the sale, average CPU is pinned at 100%, request latency triples, and the scaling group has only reached 9 instances. Investigation shows each new ECS instance takes roughly 6 minutes to boot, install the app, and pass the SLB health check. The application also holds an in-memory session cache that is lost when instances are recycled.
1. The target-tracking policy at 60% CPU did not prevent saturation. Explain why target tracking behaved this way and what the team should change so capacity is ready before the sale begins.
Read the worked answer
Target tracking is reactive: it adds capacity only after the metric breaches the target, and it adds in increments governed by cooldowns and the scale-out step. With a 6-minute instance warm-up and a 6x traffic spike arriving in minutes, the group is always chasing a moving target, and by the time new nodes are healthy the load has already grown.
The fix is to stop relying on reactive scaling for a known event:
- Pre-scale on a schedule. Use a scheduled scaling action to raise the desired capacity (and the minimum) to the expected peak ~15–20 minutes before the sale starts, so capacity is warm when traffic arrives. Return to baseline after the window.
- Account for warm-up. Set an appropriate instance warm-up / cooldown on the scaling group so metrics from booting instances are not counted, and so scaling does not stall waiting on them.
- Use a faster path to capacity. Pre-baked images (custom images or launch templates with the app pre-installed) cut the 6-minute bootstrap dramatically.
- Keep target tracking as a safety net, not the primary mechanism, and set the target below the saturation point (e.g., 50–55%) to leave headroom.
Scheduled pre-scaling plus faster bootstrapping is what turns a reactive loop into capacity that is ready before demand.
2. The in-memory session cache is a concern during rapid scale-out and scale-in. What architectural change addresses this, and how does it interact with the Auto Scaling design?
Read the worked answer
Move session state out of the instance and into a shared, external store - for example ApsaraDB for Redis (or a database) - so any instance can serve any user's session. This makes the web tier stateless, which is the precondition for clean horizontal scaling.
Interactions with the Auto Scaling design:
- Scale-in becomes safe. Instances can be removed without dropping active sessions, so the group can shrink quickly after the sale.
- No sticky-session dependency. The SLB does not need session affinity, so load is distributed evenly and a single hot instance cannot pin a user.
- Health checks and warm-up still matter. New instances must connect to the shared store and pass health checks before receiving traffic; the warm-up period should cover that connection.
- Choose the store's capacity for peak. The Redis instance must be sized for the 6x session load, and should be deployed with high availability so it does not become the new single point of failure.
Statelessness plus a managed shared cache is what makes the scaling group behave predictably in both directions.