Scheduled Elastic Scaling¶
Forecast-driven scaling policy — instantiates Elastic Capacity Scaling
Pre-positions capacity against a forecast of a known cycle — season, day-part, or scheduled event — so it is already in place when the predictable peak arrives, sized to hold the service target.
Where a reactive loop waits for a signal to cross a line, Scheduled Elastic Scaling acts on the calendar. It uses a forecast of a recurring or announced peak to stage capacity ahead of demand, so the capacity is already present when the surge lands. What makes it this mechanism is that it is pre-emptive and forecast-driven: it deliberately trades some over-provisioning during the run-up for the certainty of being ready, and it sizes that staged capacity backward from the service target it must hold at the known peak — not from any live metric.
Example¶
A grocery chain knows Thanksgiving week cold: the Wednesday before is the year's busiest checkout day, and the rush builds over an hour, not minutes. A reactive trigger would fail here — cashiers can't be conjured as lines form. So the store works from last year's transaction curve plus this year's forecast to schedule extra cashiers and open every self-checkout lane from 10am Wednesday, sized to hold the target "no customer waits more than ≈6 minutes." Capacity is in place before the first wave, then stepped back down Wednesday evening on the same schedule. The store never sensed the peak in real time; it predicted it and was ready.
How it works¶
- It is built from a forecast of a predictable cycle — seasonality, a day-part, an announced event — not a live signal.
- Capacity is sized backward from the service target that must hold at the forecasted peak.
- Capacity is staged ahead of demand, accepting deliberate over-provision during the ramp as the price of readiness.
- It fits best where lead time to add capacity exceeds the peak's onset — people, rooms, cold-start-heavy resources.
Tuning parameters¶
- Lead margin — how far ahead of the forecasted peak to stage; more margin guarantees readiness but wastes capacity during the run-up.
- Forecast horizon & refresh — how far out and how often the forecast is re-cut; a stale schedule pre-stages for demand that has since moved.
- Peak percentile — size to the median forecast or a high percentile; a higher percentile buys safety at the cost of more idle capacity.
- Blend with reactive — schedule the predictable base and leave a reactive trigger for the residual surprise.
When it helps, and when it misleads¶
Its strength is that it is the only elastic move that works when capacity is slow to add: it beats the lead-time problem by acting before demand arrives rather than chasing it.
It misleads when the forecast is wrong — the peak arrives off-schedule, or a regime shift breaks the historical cycle[1] — and you pay for staged capacity that demand never came to meet. The classic misuse is a schedule copied from last year and never revised, so the system faithfully pre-stages for a pattern that has drifted. The discipline is to refresh the forecast, size to a defensible percentile rather than the mean, and pair the schedule with a reactive trigger for the unpredictable remainder.
How it implements the components¶
demand_forecast— the forecast of the known cycle or announced event that drives the staging schedule.service_level_or_performance_target— the target the staged capacity is sized to hold at the peak; the schedule exists to keep it.
It does not sense live load or set trigger levels — that is the Queue-Based Scale Trigger; nor does it actuate the capacity, which is Cloud Autoscaling or Surge Team Activation.
Related¶
- Instantiates: Elastic Capacity Scaling — it supplies the forecast-and-target side, pre-positioning capacity before the predictable peak.
- Sibling mechanisms: Queue-Based Scale Trigger · Cloud Autoscaling · Modular Capacity Expansion · Expandable Facility Plan · Flexible Staffing Roster · Just-in-Time Resource Provisioning · Self-Service Capacity Deflection · Supplier Release Contract · Surge Team Activation · Demand-Based Budgeting
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Scheduled Elastic Scaling operates by maintains forecast-staged capacity sized ahead of predictable demand peaks. That concrete deployed or enacted form is Structure, Architecture & Configuration under the frozen taxonomy.
Nearest alternative: Rule, Policy & Commitment — Although Rule, Policy & Commitment can support this mechanism, the frozen evidence makes its operative form the act that maintains forecast-staged capacity sized ahead of predictable demand peaks; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Pre-scaling computing capacity for predictable peaks is cloud and software operations.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: pre-positions capacity against a forecast of a known cycle — season, day-part, or scheduled event — so it is already in place when the predictable peak arrives, sized to hold the….
- Operations Research — Forecast-based capacity planning materially sizes resources to service targets.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate_origin_disagreement, origin_mode_disagreement starts from reviewer_a's mechanism-specific evidence: Pre-scaling computing capacity for predictable peaks is cloud and software operations. Reviewer A proposed alternates=operations_research, origin_mode=convergent, domain_reach=specialized, and encyclopedia_synthesis=false; reviewer B proposed alternates=engineering_design, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (operations_research, engineering_design) without an arbitrary cap, selects origin_mode=convergent to represent the combined lineage evidence, and records domain_reach=specialized and encyclopedia_synthesis=false. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Scheduling and reactive triggering are complements, not rivals. The strongest designs schedule the predictable base of demand and leave a live trigger to catch whatever the forecast missed — the schedule shrinks the surprise the trigger has to absorb.
References¶
[1] Lorido-Botran, T., Miguel-Alonso, J., and Lozano, J. A. “A Review of Auto-scaling Techniques for Elastic Applications in Cloud Environments”. Journal of Grid Computing 12(4): 559–592 (2014). Warns that proactive auto-scaling depends on forecast accuracy, which varies with workload pattern, burstiness, history window, and prediction interval. registry ↩