Key idea
Horizontal scaling runs more identical spherelets and spreads requests across them. It adds capacity for traffic and keeps the service up when one copy fails, but only if any spherelet can answer any request.
When more spherelets help
The service copes with light traffic and struggles with heavy traffic: p95 latency and CPU climb together as requests go up, and fall when they drop. Each request is fine on its own; there are just too many at once for one copy. Two spherelets each take about half.
If one request is slow even when nothing else is happening, more copies won't help. That's a job for a bigger shape (previous lesson) or for the code.
The catch: state
Every spherelet has its own memory and its own filesystem. Anything the app keeps in either is visible to one copy only (lesson 5.5.1).
learn-shop-api shows the problem on purpose. It keeps orders in memory. On one spherelet, POST /orders then GET /orders shows your order. On two, the GET may reach the other copy and come back without it. The same goes for sessions held in memory, uploads saved to a local folder, and a SphereStor volume, which attaches to one spherelet at a time.
Before you scale out, move that state to a database, object storage or a shared cache. Then the count is just a number you can change.
Changing the count
csph services list
csph deployments list --service <service-id>
csph deployments scale <deployment-id> --spheres 2
--count does the same as --spheres. The service rolls out to the new count and returns to Running.
Open the service, then Settings. On the Spherelets card choose Edit, set Spherelets to 2, choose Save, then Save & redeploy.
Changing the count doesn't record a new version; it runs more or fewer copies of the one you have. Scaling down works the same way, with a smaller number.
A fixed count doesn't follow the load
Two spherelets run all day, busy or not. If your traffic has a daily peak, you pay for the peak around the clock, and a spike bigger than you planned for still overwhelms them. Letting the count follow CPU is the next lesson.
Check yourself