Topic 9.8
Autoscaling
In one line
Add and remove instances by demand signals — the automation that turns capacity into a managed cost.
Think of it like this
A restaurant calling in extra part-time waiters when it suddenly gets busy on a Saturday night, and sending them home once things quiet down, rather than keeping the same big staff on payroll every single day.
Key ideas
- 01
Scale on what?: CPU, memory, queue depth, request latency, custom metrics (orders/minute).
- 02
Cooldowns & stabilization: avoid flapping — grow fast (scale up quickly), shrink slowly (the famous 'scale down after 10 min idle').
- 03
Predictive + reactive: scheduled scaling for known peaks (diwali sales, year-end), reactive for the rest.
- 04
The web layer is the EASY part — the DB (single writer) doesn't auto-scale nicely; the queue and reads absorb the spike.
- 05
Cold start reality: container spawn takes minutes; design for minutes, not seconds.
- 06
Interview line: 'web tier autoscales on CPU and queue depth; the DB is pre-scaled because it cannot.'
Java / Spring map
- →
K8s HPA on custom server metrics; or cloud autoscaling groups keyed on the app's own metrics.
Explain without notes
Why does autoscaling the read replicas beat autoscaling the primary for a read-spike product?
Practice
Write the scaling policy (metric, thresholds, cooldown) for a ticket-booking launch day.
Trade-offs
- ↔
Autoscaling optimizes cost at the risk of latency during cold starts; pre-warm big events.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can articulate what scales automatically and what must be pre-provisioned.