Scaling & service health
Separate capacity from correctness
Lesson 18 of 20 · 12 min · Module 6: Recover a complete service
More replicas can add capacity without repairing a defective version.
Start this lesson →Free. No installation: you write and run the code in your browser, and it is checked automatically.
By the end, you’ll be able to…
- Identify the reason to scale
- Keep version identity stable
The idea
This practice runbook is an ordered sequence of the teaching actions named in the task. Each action changes or observes the supplied in-memory scenario.
01Identify the reason to scale
Capacity symptoms such as sustained load and queueing can justify more instances. A deterministic application error needs a different repair.
02Keep version identity stable
This change increases the modeled replica count while leaving the known-good image untouched. Avoid mixing unrelated changes during diagnosis.
03Verify the resulting contract
A health check should still pass after scaling. Real scaling also needs resource capacity, load distribution, and application behavior under multiple instances.
Your turn
What the checks look for
- Changes capacity without changing release
- Checks the healthy result
Take this with you
Change capacity only when the evidence supports that hypothesis.
Go a little further
Choose metrics that would distinguish CPU pressure from an application validation error.