Autoscaling, reactive and scheduled

An autoscaler changes the number of running copies to follow demand, so you pay for the peak only while it lasts.

Use it when#

Traffic has a daily shape, so a fixed fleet is idle at night and short at noon.
Spikes arrive faster than a person can add servers.
The tier is stateless, so a new copy can take traffic as soon as it boots.

How it works#

A reactive policy reads a signal, such as CPU, requests per copy, or queue depth for workers. It compares the signal with a target and adds copies when it passes. A new copy takes time to boot and warm up, so a reactive policy always trails the load. A min keeps the floor high enough to survive a failure, and a max caps the bill.

A scheduled policy adds copies before a known peak, such as 9 a.m. on weekdays, so they are warm when users arrive. Reactive scaling then handles whatever the schedule missed.

What it costs#

Boot time is the weak point: scaling at the moment of a spike is too late for a slow-starting runtime. Aggressive scale-in causes flapping, and a missing max turns a bot flood into a large bill. Signal choice matters too. CPU misses a service that waits on a slow database.

In Quorum#

Link an App Server into an Autoscaler after researching Autoscaling. The schedule switch needs Scheduled scaling. The Design pairs it with slow start on the Load Balancer, so a new copy takes traffic gradually.

Drag to pan. Hold Ctrl or Cmd and scroll to zoom.

At 3.00k Users the Simulation solves this Design to Apdex 0.99, p99 435 ms, 0.0% errors and $3.84/s Burn.

Where	Setting	Value	Why
Load Balancer	Slow start	On	A new copy takes traffic gradually, so a copy that boots in the middle of a spike never meets it cold.
App Server	Instance size	small	Small gives the app two vCPUs, enough to run code while the data tier does its own work.
App Server	Copies serving now	3	The Autoscaler chooses this number as load moves. It is fixed here only to show a point in time.
Autoscaler	Signal	cpu	The Autoscaler reads CPU load. Load covers slots and memory too, requests per copy suits uneven requests, and queue depth suits Workers.
Autoscaler	Target	0.6	It adds copies when load passes this share and removes them when load falls well below it. A lower target keeps more headroom.
Autoscaler	Min copies	2	The floor keeps two copies running at night, so one failure never leaves the tier empty.
Autoscaler	Max copies	8	The ceiling caps the bill when a bot flood or a bug drives the signal up.
Autoscaler	Schedule	On	It adds copies ahead of the known daily peak, so they are warm when the peak arrives and not still booting.
Database	Instance size	small	Small gives the Database two vCPUs, so the figures below reflect the Cache and not a starved Database.

Research this Design needs: Load balancing, Autoscaling, Scheduled scaling.

The JVM warmup under load incident shows cold copies arriving mid-spike. The glossary defines autoscaling and diurnal traffic, and the Autoscale the compute tier rung builds it step by step.