Skip to content

CONCEPT Cited by 1 source

Seasonality (daily / weekly)

Seasonality is the property of a time series in which values recur with approximate periodicity at a named timescale — daily, weekly, monthly, yearly. It is the forecastable component of workload traffic: same pattern every Monday 09:00, same midnight Friday batch spike, same 14:00 peak every day.

Why it matters for autoscaling

Seasonality is the structural signal predictive autoscaling exploits. With several weeks of history:

  • Daily seasonality → forecast several hours ahead accurately from where the current day sits in its daily pattern.
  • Weekly seasonality → forecast days ahead from which day of week it is.
  • Long-term trend (orthogonal, not seasonal) → forecast growth / decay across weeks.

Without seasonality the forecaster falls back to extrapolating the last 1–2 hours of data (the short-term forecaster shape).

Empirical distribution (MongoDB Atlas 2023)

From MongoDB's sample of 10,000 replica sets (Source: sources/2026-04-07-mongodb-predictive-auto-scaling-an-experiment):

"Most MongoDB Atlas replica sets have daily seasonality. About 25% have weekly seasonality. Generally, if a replica set has weekly seasonality, it also has daily seasonality. Hourly seasonality is rare, and anyway, it isn't helpful for planning a scaling operation that takes a quarter-hour."

Three takeaways:

  1. Daily is the dominant signal. Most workloads are shaped by human-business-day rhythms.
  2. Weekly is a ~25% minority and adds incremental forecast accuracy over purely-daily.
  3. Hourly seasonality is structurally useless at a ~15-minute scaling-operation horizon — if the pattern is shorter than the control action, exploiting it requires in-place absorption (batching, caching), not forecasting.

Decomposition via MSTL

MongoDB's long-term forecaster uses MSTL (Multi-Seasonal Trend decomposition using LOESS) from the statsmodels / R forecasting literature. MSTL splits a time series into three additive components:

y(t) = trend(t) + seasonal(t) + residual(t)

with multiple seasonal components for multiple periodicities (daily + weekly). Residuals are fed to a simple ARIMA autoregressive model for short-term noise modelling. Forecast = recomposition: extrapolated trend + learnt seasonality + ARIMA-predicted residuals.

Detecting seasonality

Common techniques (not all named in the MongoDB source):

  • Spectral analysis — Fourier transform, look for peaks at 1-day / 1-week / etc. frequencies.
  • Autocorrelation — high autocorrelation at lag = period length.
  • Out-of-sample error — MSTL with daily+weekly vs. MSTL without; if adding weekly reduces held-out error, weekly seasonality is present.
  • Domain heuristics — business-hour workloads are almost always daily-seasonal; batch-job replica sets may be weekly.

Why hourly fails the scaling-horizon test

Scaling ops on MongoDB Atlas take several minutes; the useful forecast horizon is ~15 minutes or longer. An hourly-seasonal spike lasts at most ~60 minutes and may have already peaked and passed by the time scaling completes. The ratio of forecast horizon to pattern period determines whether a seasonality is forecast-actionable — if the pattern repeats inside one scaling op, you can't scale between patterns, you can only scale once to handle the whole day's worth.

Seasonality vs. trend

Often confused:

  • Trend — monotonic growth / decay across many periods ("this replica set's query load is steadily growing").
  • Seasonality — periodic component with fixed amplitude, superimposed on the trend.
  • Residual — unexplained noise after stripping both.

MSTL separates all three; MongoDB's forecaster uses all three components.

Cold start

A newly-created replica set has no daily seasonality observable for at least a few days, no weekly observable for at least 2 weeks. The MongoDB source doesn't discuss cold-start explicitly, but the implication: new replica sets must run under pure reactive scaling + short-term forecasting until the seasonality window fills.

Seen in

Last updated · 200 distilled / 1,178 read