Z3 · Scalability & Performance

Autoscaling

Gold

Autoscaling adds servers when a metric such as CPU crosses a threshold and removes them when load falls, so capacity follows traffic instead of being sized for the peak all day.

Use when: Traffic that rises and falls through the day · Stateless tiers behind a load balancer
Avoid when: Stateful tiers such as the primary database · Spikes shorter than an instance's start-up time — keep headroom instead
Trade-offs: Reaction lag vs cost — a higher minimum is safer and pricier · Thresholds too close together make the fleet flap · A maximum caps the bill and the capacity
Requires: Horizontal scaling with a stateless tier

3 objectives · 8 misconceptions

predict Predict the instance count over a traffic curve, given the thresholds and the time a new instance takes to start.
explain Explain why autoscaling reacts late to a sudden spike, and how a minimum and headroom cover the gap.
choose Choose the scaling metric and thresholds — CPU, response time or queue length — and which tiers can autoscale at all.

Not true: New servers appear the moment traffic rises.
Not true: Autoscaling removes the need to plan capacity.
Not true: Any tier can autoscale the same way, including the database.
Not true: CPU is always the right metric to scale on.
Not true: Removing servers carries no risk.
Not true: An autoscaled web tier drops to zero instances when traffic is low.
Not true: An autoscaler only adds instances; it keeps whatever it added.
Not true: Scale-up and scale-down thresholds close together keep the fleet at exactly the right size.

Learn

Autoscaling that keeps upMembers~12 min

Practice

Pixel goes viralMembershard

Check

Station test-out80% to pass

Neighborhood

builds onHorizontal scaling with a stateless tier

→Autoscaling→

unlocksAutoscale economics

contrast withRight-sizing

On linesScale Line