Scaling the control plane with the fleet
The control plane has to keep track of every server and every customer using its service. The bigger your fleet grows, the more there is to track. A tiny brain that was fine for ten servers chokes when it is suddenly responsible for a thousand. When that happens the service does not crash outright -- it gets slow and sloppy: new requests pile up, growth stalls, and customers feel the lag.
When a brain is overloaded you have two moves. Give it a bigger home -- move the control plane onto a beefier server with more CPU and memory (scaling up). Or split the job across more brains that share the load (scaling out). Either way the lesson is the same: the brain has to grow with the business. A five-thousand-machine cloud cannot be run from a spare mini-PC in the corner, and pretending otherwise is how you end up with an outage on your busiest day.
Detailed explanation
Control-plane need scales as need = base + per_agent_host x N_agent_hosts + per_unit x N_units. The running instance(s) carry a provisioned capacity; when need > capacity the control plane is overloaded -> scheduling lag, growth stalls, degraded serving, and an incident. This is the deliberate forcing function that makes the control plane grow with the fleet rather than sit free in the background.
Fix it by scaling vertically (a larger control-plane host) or horizontally (more replicas / shards spreading managed_load). Horizontal also buys you the resilience story -- see control-plane HA. Watch the per-unit term: a class with many managed units (buckets-per-100GB, K8s nodes) grows the control-plane bill faster than raw host count alone.