At 09:00, a predictable traffic wave arrives, the autoscaler detects it, and the new VM is still booting when demand has already reached its peak. Capacity shifting handles the same event differently: the predicted wave causes capacity to move to the appropriate PoP before the traffic arrives.
This is the distinction we built into Symbiosis. Autoscaling is a response mechanism. Capacity shifting is a pre-positioning mechanism. Both have a place in distributed infrastructure, but they solve different timing problems.
The timing problem with reactive scaling
An autoscaler generally waits for a signal from the workload or infrastructure. That signal might be rising request volume, CPU utilization, queue depth, or another threshold. Once the threshold is reached, the system requests additional capacity. The platform then provisions a VM, initializes it, connects it to the relevant services, and makes it ready to receive work.
That sequence takes time. Standard VM autoscaling boot time is typically 30 to 120 seconds. For many workloads, that delay is acceptable. A gradual increase in demand gives the new instance time to become useful. A queue can absorb some additional work. A service can tolerate a temporary increase in latency.
Other workloads do not provide that margin. Their traffic changes faster than the infrastructure can respond. In those cases, an autoscaler can be behaving correctly and still fail to protect the workload at the moment protection is needed. It sees the event, triggers the action, and begins provisioning. The problem is that the peak arrives before the action is complete.
A weekly spike, handled two ways
Consider a synthetic workload with a strong weekly pattern. Every Monday morning, traffic rises sharply in a particular region. The increase is not necessarily surprising. It is a recurring wave with a recognizable shape, but it develops too quickly for a newly booted VM to be ready at the start of the peak.
With conventional autoscaling, the sequence looks like this:
- Traffic begins to rise.
- The scaling signal crosses its threshold.
- The autoscaler requests one or more VMs.
- The VMs boot and join the serving pool.
- The additional capacity becomes available after the wave has already started.
Capacity shifting changes the first step. The AI prediction model identifies the expected wave and provides a 40-second lead time. That lead time is used to move capacity toward the right PoP before the spike peaks. The capacity is not waiting for the workload to become overloaded before changing location. It is positioned in anticipation of the traffic pattern.
For a distributed platform, location matters as much as quantity. Capacity in the wrong region may not address the immediate demand, even if the total amount of capacity across the system looks sufficient. Symbiosis operates across 12 PoPs on 5 continents, so the architectural question is not only how much capacity is available. It is also where that capacity should be placed before a wave arrives.
What capacity shifting actually changes
Capacity shifting does not mean that infrastructure appears instantly. It changes when and where the platform takes action. Instead of treating demand as an event that begins at the first threshold crossing, the system uses a predicted event to prepare the serving location in advance.
The 40-second lead time is important because it changes the relationship between prediction and provisioning. If a workload spikes faster than a VM can boot, reacting at the threshold is too late. Acting before the peak creates time for capacity to be moved to the relevant PoP while the existing serving layer continues handling traffic.
This also changes how we think about control planes. A reactive control loop asks, “Is demand high enough to add capacity now?” A predictive control loop asks, “Where is demand likely to be, and what should be in place before it arrives?” Those are related questions, but they produce different system behavior.
At Symbiosis, capacity shifting can operate without a human in the loop unless a human is desired. That matters for recurring operational patterns. A team can choose to let the system make these adjustments automatically, or retain a human decision point where the operating model requires it. The architectural capability is the same: move capacity before the trigger associated with the spike becomes the first source of information.
We are not replacing autoscaling
We are not saying autoscaling is wrong; we are saying for workloads that spike faster than a VM boots, you need something that acts before the trigger fires.
Autoscaling remains the right choice for many workloads. It is a good fit when demand changes gradually, when the service has enough queueing or latency tolerance to absorb provisioning time, or when traffic is difficult to predict. It is also useful for handling ordinary variation around a baseline. A system should not pre-position capacity for every small fluctuation if a reactive adjustment is sufficient.
Capacity shifting does not help every workload. It cannot create useful prediction where there is no meaningful signal. A genuinely random burst, an isolated failure, or a demand pattern with no repeatable structure may not provide enough lead time for pre-positioning. Capacity shifting is also not a replacement for application-level backpressure, efficient request handling, or sensible capacity limits. It addresses a specific infrastructure timing problem.
The practical decision is therefore not “autoscaling or capacity shifting” as a universal platform choice. It is a question of which control loop matches the workload. If demand is gradual or unpredictable, reactive scaling may be the simpler and more appropriate mechanism. If demand is recurrent, geographically identifiable, and faster than a VM boot cycle, pre-positioning can address a gap that threshold-based scaling cannot.
Designing around the lead time
Every predictive system has to be evaluated against the time available to act. A prediction is useful only when its lead time is long enough for the infrastructure operation to complete and for the capacity to become available where it is needed.
That is why the comparison with VM boot time matters. A 40-second prediction window does not make every scaling problem disappear. It does provide an actionable interval for the class of workloads where a reactive system would start provisioning too late. The engineering work is in connecting that interval to placement, capacity movement, and service readiness rather than treating prediction as a dashboard signal alone.
The result is a different architecture for a narrow but important class of workloads. Autoscaling waits for evidence that demand has arrived. Capacity shifting uses an expected wave to prepare the network edge before the peak. When the timing of the workload is the problem, changing the timing of the control loop is the solution.