Campaign and e-commerce peaks, load balancer in place
The highest-fit case after the fully prepared one: the load balancer exists, the peaks are known, and the only missing feature is planning for them. Scheduled scaling is a Pro feature; everything else, including self-healing and the cost guard, is in every plan.
- Prerequisite work
- none; wants scheduled scaling
- Time to set up
- 20 min
- Adapter
- Snapshot or webhook
- Fit
- 9/10
Prerequisites, time and fit are the ADR-0028 row for this case. Hetscale's own setup is about 15 minutes in every case; the rest is work on your side.
Steps
- 01Connect read-only
The day-0 report from your last 30 days shows the peaks, how often capacity fell short and a ranged cost. Campaign days with CPU pinned at 100% are flagged.
- 02Rehearse, then go Live
One Rehearsal, then a range wide enough for the next campaign: minimum 2, maximum what the report suggests for the peak.
- 03Schedule the known peaks
Scheduled scaling (Pro and above) raises the minimum before a launch or a sale so the nodes are already healthy when the traffic arrives, instead of reacting to it.
- 04Keep a fallback type in the template
Campaign days are when a server type is most likely to be out of stock in your location. Allow a fallback type or location; fallback nodes are removed first when the peak is over.
FAQ for this case
What happens if the server type is out of stock during the sale?
The fallback type or location you allowed is used; if the whole chain is exhausted the group is marked in capacity deficit and you are notified. Stock is observed centrally and a create is skipped, never retried blindly.
Will scaling in cut a customer’s checkout?
Scale-in removes the node from the load balancer first and waits the drain window (default 60 s, up to 300 s) before shutting it down. Raise the window if checkouts hold long connections.