How would you design autoscaling for a workload with a sharp, predictable daily spike versus one with genuinely unpredictable bursty traffic?

For the predictable spike, combine scheduled pre-scaling (raising minReplicas shortly before the known spike, then lowering it after) with HPA as a safety net for any deviation from the expected pattern — this removes the reactive-scaling latency entirely for the part of the load you can already predict. For genuinely unpredictable bursts, scheduled pre-scaling isn't an option at all, so the design instead focuses on minimizing HPA's reaction latency (faster metrics, tighter sync intervals, generous scaleUp behavior policies) and maintaining enough standing headroom to absorb the first several seconds of a burst before new replicas can come online.

Both scenarios share the same underlying constraint — reactive scaling has structural latency that no configuration eliminates — but they diverge sharply in what's available to compensate for it. Knowing the spike's timing in advance turns the problem into a scheduling exercise; not knowing it turns the problem into minimizing reaction time and accepting some standing cost instead.

• The predictable-spike workload should have new capacity ready before the spike hits, not reactively during it.
• The bursty workload needs to minimize the delay between load increasing and new capacity becoming available, since its timing can't be anticipated.
• Neither design should pay for standing capacity it doesn't need outside of when it's actually justified.

Predictable spike: scheduled pre-scaling closes the reactive-latency gap entirely: since HPA's reactive scaling has structural latency (metrics collection, sync interval, stabilization window, pod startup time), and the spike's timing is known in advance, the better design sidesteps that latency — a CronJob-triggered patch to the HPA's minReplicas (raising it shortly before the known spike time, lowering it back down afterward) ensures capacity is already provisioned and warm before load actually arrives, rather than reacting to it. HPA remains active throughout as a safety net for any load beyond what was anticipated.

Predictable spike: lead time needs to account for the full pod startup chain, not just replica count: raising minReplicas triggers pod creation, but the new pods still need to be scheduled, start, and pass readiness checks before they're actually useful — scheduling the minReplicas increase with enough lead time (minutes, not seconds, depending on the application's startup time) before the actual spike ensures capacity is genuinely warm, not just "requested," when load arrives.

Bursty traffic: minimize HPA's own reaction latency, since pre-scaling isn't available: tightening the metrics pipeline's freshness, reducing scaleUp.stabilizationWindowSeconds toward zero (accepting more responsiveness to noise as the trade-off, since for a bursty workload you generally want fast reaction more than smoothing), and using aggressive scaleUp.policies (allowing a large jump in replica count per evaluation cycle rather than a conservative incremental increase) collectively shrink the window between load arriving and new capacity coming online.

Bursty traffic: maintain standing headroom to absorb the first moments of a burst: since even a well-tuned HPA can't react instantaneously, keeping minReplicas somewhat above the workload's typical baseline (accepting some ongoing cost) gives existing capacity room to absorb the immediate first seconds of a burst while HPA's reactive scaling catches up — this is a deliberate cost/responsiveness trade-off, not something to default to for every workload.

Both designs benefit from fast-starting pods: minimizing container image size, avoiding slow application initialization, and using accurate (not overly conservative) readiness probe timing directly reduces the "new pod exists but isn't Ready yet" portion of the latency chain for both cases — this is a shared lever that helps regardless of which scaling strategy is primary.

Scheduled pre-scaling for the predictable case requires knowing the schedule accurately and maintaining that scheduling mechanism (a CronJob or equivalent) as a real piece of infrastructure — if the actual spike timing drifts from the assumed schedule, this can either waste cost (scaling too early) or fail to help (scaling too late). Standing headroom for the bursty case is a direct, ongoing cost paid regardless of whether a burst actually occurs during any given period — the right amount of headroom is a genuine cost/risk trade-off that needs to be revisited as traffic patterns evolve, not set once and forgotten.

• For predictable spikes, scheduled pre-scaling (raising minReplicas ahead of time) removes reactive-scaling latency entirely — HPA remains active as a safety net for deviation from the expected pattern.
• Lead time for pre-scaling needs to account for the full pod startup chain (scheduling, startup, readiness), not just the moment minReplicas changes.
• For unpredictable bursts, the design instead minimizes HPA's own reaction latency (faster metrics, tighter stabilization, aggressive scale-up policies) and accepts some standing headroom as a cost/responsiveness trade-off.
• Fast pod startup time is a shared lever benefiting both strategies, independent of which one is primary for a given workload.

• Kubernetes: Horizontal Pod Autoscaling — Support for Scaling Behavior
• Kubernetes: CronJob