Forecasting and Time-Series Analysis Questions

Direct answer
A low-latency (100ms p95, 500 QPS, 10k zones) forecasting service needs pre-computed or cached predictions wherever possible (rather than computing a fresh forecast per request), an online feature store fast enough to serve the remaining real-time inputs within the latency budget, a model store supporting fast model loading/versioning, and explicit availability/rollback strategies given the operational stakes of a customer-facing latency SLA.

Structured elaboration

• Model store: hosts versioned, trained models ready for fast loading into the serving layer; at 10k zones, likely one (or a small number of clustered) GLOBAL models rather than 10k independently-loaded per-zone models, both for the same statistical pooling reasons that favor global models at scale and for the practical serving reason that loading 10k separate model artifacts per request path is operationally unworkable within a 100ms budget.
• Feature store, online features: the features needed at inference time (recent lag values, calendar features, any real-time exogenous signal) must be servable with very low latency - a dedicated online feature store (backed by a fast key-value store, not a query against a data warehouse) is standard here, since a warehouse query would blow the 100ms budget on its own.
• Caching: for a request pattern where many requests ask for the SAME zone's forecast within a short window (a very plausible pattern at 500 QPS across "only" 10k zones), caching a recently-computed forecast (invalidated on a schedule matching how often the underlying forecast is genuinely refreshed, e.g. every 15 minutes) avoids recomputing an identical answer repeatedly, and is often the single biggest lever for hitting a tight latency SLA without needing every request to hit the full model-inference path.
• Serving batched predictions: even for on-request serving, batching multiple zones' feature vectors into one model inference call (rather than one model call per zone) amortizes fixed per-call overhead and is usually meaningfully faster in aggregate than fully independent per-request inference, especially for a model architecture (e.g. a global gradient-boosted or neural model) that scales well with batch size.
• Availability and rollback: run multiple redundant serving instances behind a load balancer so a single instance failure doesn't violate the latency SLA for other requests; deploy new model versions via a canary (a small slice of traffic first) with automated rollback if the new version's latency or accuracy regresses, rather than a full instantaneous cutover.

Worked example
A concrete architecture: features refreshed into a fast online store on a schedule (e.g. every few minutes) rather than computed synchronously per-request; a background job pre-computes and caches each zone's forecast at the SAME refresh cadence; the actual request-serving path becomes largely a cache lookup (very fast, easily within 100ms even at 500 QPS) with a fallback to synchronous on-demand inference only for a cache miss (a zone whose forecast hasn't been pre-computed recently, ideally a rare case) - this architecture trades a small amount of freshness (forecasts are as fresh as the last refresh cycle, not literally real-time) for a much more reliable and cheaper latency profile than computing everything synchronously per request.

Trade-offs & pitfalls
The most consequential design trade-off here is freshness vs latency/cost: pure synchronous per-request inference gives the freshest possible forecast but is the most expensive and riskiest way to hit a tight SLA at this request volume; a pre-compute-and-cache architecture is cheaper and more reliably fast but serves a slightly staler forecast - the right balance depends on how much genuine value fresher-than-cache-refresh-cycle forecasts actually provide for THIS specific use case (per-zone 15-minute demand predictions), which is worth validating rather than assuming synchronous freshness is automatically worth its cost.

Direct answer
EWMA maintains a smoothed value updated recursively as $S_t = \alpha x_t + (1-\alpha) S_{t-1}$, where alpha controls the trade-off between responsiveness (high alpha, reacts fast, passes through more noise) and noise reduction (low alpha, smoother, slower to react); a practical heuristic for choosing alpha to detect a specific-size shift (e.g. a sudden 10% drop) is to pick alpha large enough that the EWMA visibly moves toward the new level within a small number of periods, without being so large that ordinary day-to-day noise alone crosses your alerting threshold.

Structured elaboration and worked example (executed)

import numpy as np

def ewma(values, alpha):
    out = np.empty_like(values, dtype=float)
    out[0] = values[0]
    for t in range(1, len(values)):
        out[t] = alpha * values[t] + (1 - alpha) * out[t - 1]
    return out

Run with alpha=0.2 on a series with a baseline around 100 that shifts to a sustained ~112 (a +12% shift) partway through:

baseline EWMA mean (last 5 of baseline): [100.88 101.52 100.32 101.03  99.65]
EWMA after shift (last 5): [110.29 109.89 112.19 110.97 110.1]

The EWMA converges close to the new level within roughly 10-15 periods at alpha=0.2. A larger alpha would converge faster but track single-point noise more closely; the choice is a genuine sensitivity/false-alarm trade-off, not something with one universally-correct answer.

• How alpha controls the trade-off: a HIGH alpha weights the newest observation heavily, so the EWMA follows the raw series closely (fast to detect a real shift, but also reacts to a single noisy point - more false alarms if used directly as an alerting signal); a LOW alpha smooths heavily over many past observations (slow to detect a real, sustained shift, but robust to single-point noise).
• Heuristic for choosing alpha to detect a specific target shift: think in terms of an effective "memory" window - an EWMA with parameter alpha weights recent observations roughly like a moving average of window size $\approx \frac{2}{\alpha} - 1$; to detect a sustained 10% drop reliably within, say, 5 periods without over-reacting to single-point noise of a known typical size, choose alpha so this effective window is short enough to react within your desired detection latency, then validate empirically (as done above) that ordinary noise alone doesn't cross your intended alerting threshold at that alpha.

Trade-offs & pitfalls
EWMA (like CUSUM) is fundamentally a SMOOTHING/tracking statistic, not by itself a full alerting system - turning it into one requires an explicit threshold and a decision about how to define "baseline" in the first place (especially on a series with its own trend/seasonality, where the EWMA needs to track a MOVING baseline, not a fixed constant, or every seasonal peak will look like a shift). The single most common mistake is choosing alpha (or a threshold) by convention rather than validating against the ACTUAL noise characteristics of the specific metric you're monitoring, since two metrics with very different natural variance need different alpha/threshold combinations to hit the same false-alarm rate.

Direct answer
A practical decomposition-residual anomaly detector: run seasonal decomposition, compute the Median Absolute Deviation (MAD) of the residual, flag points whose residual is more than a chosen number of MADs from the median (a robust z-score), and treat known holidays as either excluded from threshold-fitting or modeled explicitly rather than left to trip the same generic threshold as an unexplained anomaly.

Structured elaboration and worked example (executed)
Against a synthetic 180-day daily series (seed=0: linear trend + weekly sinusoidal seasonality + Gaussian noise) with 3 known injected anomalies (two +300 spikes at indices 60 and 120, one -300 drop at index 150):

import numpy as np, pandas as pd
from statsmodels.tsa.seasonal import seasonal_decompose

np.random.seed(0)
n = 180
t = np.arange(n)
y = 1000 + 2*t + 50*np.sin(2*np.pi*t/7) + np.random.normal(0, 15, n)
y[60] += 300; y[120] += 300; y[150] -= 300

result = seasonal_decompose(pd.Series(y), model="additive", period=7, extrapolate_trend="freq")
resid = result.resid.dropna()
mad = np.median(np.abs(resid - np.median(resid)))
robust_z = 0.6745 * (resid - np.median(resid)) / mad
flagged = resid.index[np.abs(robust_z) > 3.5]

Executed result:

Injected anomaly indices: [60, 120, 150]
MAD-flagged indices (threshold 3.5): [60, 120, 121, 150, 151]
True positives: [60, 120, 150]
False positives: [121, 151]

All 3 injected anomalies were correctly detected at threshold 3.5, with 2 false positives immediately adjacent to two of the true anomalies - a real and expected pattern: weekly seasonal decomposition can partially "smear" a sharp anomaly's effect into an adjacent day's residual through the seasonal-averaging step, which is a genuine practical trade-off (a tighter threshold reduces these adjacent false positives but risks missing smaller genuine anomalies).

• Selecting thresholds to control false positives: MAD-based robust z-scores are preferred over plain standard-deviation z-scores because the SD itself is inflated by the very anomalies you're trying to detect, while the median-based MAD is robust to them; the threshold (here 3.5) trades off sensitivity vs false-positive rate, and should be tuned against a labeled historical set of known true/false anomalies where available, rather than picked by convention alone.
• Handling known holidays or seasonal events: a fixed weekly-seasonal decomposition has no way to represent a one-off holiday's effect, so a holiday will look like a large residual and either get flagged as a false-positive "anomaly" or, if severe enough, distort the fitted seasonal profile itself. Two practical fixes: exclude known holiday dates from the data used to FIT the seasonal profile (so they don't contaminate the baseline), and either give holidays their own separate explicit effect (as Prophet's holiday component does) or accept they'll always need to be checked against a holiday calendar before treating a flagged residual as unexplained.

Trade-offs & pitfalls
MAD-on-residuals is a solid default but is still a GLOBAL threshold across the whole series - if residual variance itself changes over time (heteroskedasticity), a single global MAD will be too loose during low-variance periods and too tight during high-variance ones; a rolling-window MAD, recomputed locally rather than once over the whole history, addresses this at the cost of needing enough local history to estimate a stable MAD in each window. Always validate any chosen threshold against a small set of known true anomalies (as done above) rather than trusting a textbook multiplier (like "3 sigma") without checking it against your own data's behavior.

Direct answer
Holt-Winters (triple exponential smoothing) forecasts a series by maintaining three continuously-updated smoothed components: level, trend, and seasonality, each with its own smoothing parameter (alpha, beta, gamma). It comes in additive and multiplicative seasonal variants depending on whether the seasonal swings stay a constant size or scale with the series' level.

Structured elaboration

• Level: the smoothed "current baseline" value of the series, updated each period the same way simple exponential smoothing updates its single smoothed value.
• Trend: the smoothed estimate of the period-over-period change in level, so the model can extrapolate a rising or falling baseline rather than a flat one.
• Seasonality: a smoothed multiplier or additive offset per position in the seasonal cycle (e.g. one value per day-of-week), re-estimated each time that position in the cycle recurs.
• Additive vs multiplicative seasonality: additive assumes the seasonal swing is a roughly CONSTANT absolute amount regardless of the series' level (e.g. "+200 units every December, whether the trend level is 1,000 or 5,000"); multiplicative assumes the swing SCALES with the level (e.g. "+20% every December"). Use additive when seasonal amplitude looks flat over time on a raw plot; use multiplicative when the seasonal swings visibly widen as the series grows (a classic tell: plot the series, and if the peaks-to-troughs gap grows alongside the trend, it's multiplicative).
• Smoothing parameters: alpha controls how fast the level reacts to new observations (high alpha = very responsive, more noise passed through; low alpha = smoother, slower to react to a real shift); beta similarly controls how fast the trend estimate updates; gamma controls how fast the seasonal profile itself is allowed to drift over time. All three are typically chosen by minimizing in-sample or backtested forecast error rather than set by hand.
• When Holt-Winters is a good choice: a business series with a clear, stable trend and a clear, stable seasonal period (retail sales with weekly or yearly seasonality, subscription-metric series with weekly cycles), especially when you want something simple, fast to fit, and easy to explain (three interpretable smoothed components) rather than the heavier machinery of SARIMA or a gradient-boosted model.

Worked example
A retailer's weekly sales show a steady 2%/quarter growth trend and a consistent seasonal bump every week 51-52 (holiday shopping) of roughly the same ABSOLUTE size in dollar terms regardless of the year's overall sales level in the recent data - that constant-absolute-size signature is the additive case, so additive Holt-Winters is the natural fit. If instead the December bump had been growing proportionally as the store's overall sales grew year over year (e.g. always about 40% above the trend level, not a fixed dollar amount), multiplicative seasonality (or a log-transform plus additive smoothing) would be the better-fitting choice.

Trade-offs & pitfalls
Holt-Winters assumes a single, fixed seasonal period known in advance - it doesn't naturally handle multiple overlapping seasonalities (e.g. both weekly AND yearly patterns in daily data) the way STL-with-multiple-periods or Prophet's Fourier terms can, and it has no native way to incorporate external regressors like promotions. It's also purely extrapolative: if the underlying regime genuinely changes (a step-change in trend), Holt-Winters adapts only as fast as its smoothing parameters allow, which can mean a lagging response right when it matters most.

Direct answer
Forecasting a demand or capacity metric (like viewing hours, order volume, or active users) with strong seasonality and event-driven spikes calls for the same core toolkit as any seasonal demand forecast: a classical or ML model chosen to fit the seasonality's complexity, explicit handling of known future events (releases, holidays, campaigns), and evaluation against the operational decision the forecast actually supports (a capacity or staffing plan), not just a generic accuracy number.

Structured elaboration

• Model choice, classical vs ML: for one series with clean weekly+monthly seasonality and no meaningful external drivers, SARIMA or Holt-Winters are strong starting points. Once you need to incorporate known upcoming events (a title release, a new-market launch, a promotional campaign) as explicit regressors, or you're forecasting many related series together (many titles, many regions, many order channels), a model that supports exogenous features and pooling - Prophet with regressors, or a gradient-boosted model over lag/calendar/event features trained across all series - is the better fit.
• Handling known future events: build an explicit event/release-calendar feature (a flag, or a decaying "days since release" feature capturing the post-spike decline) rather than hoping the model infers a one-off spike from history alone; a genuinely new event type (first-ever release in a new content category) has no historical analogue for the model to learn from, so pair the model output with a judgmental adjustment or an analogue-based estimate for events without a clean precedent.
• Evaluating forecast accuracy for planning purposes: report error metrics AT THE GRANULARITY the planning decision needs (e.g. hourly RMSE if staffing is scheduled hourly, not just an aggregated daily/weekly number that could hide a systematically-missed daily peak), and evaluate coverage of the prediction interval specifically around event days, since those are exactly when planners most need the interval to be trustworthy and are also where models are most likely to be poorly calibrated.
• Scaling considerations when the metric feeds a real capacity decision: because under-forecasting a spike has an asymmetric cost (a capacity shortfall vs a modest over-provisioning cost), it's often appropriate to plan off a higher quantile of the forecast distribution (e.g. the 90th percentile) rather than the point median, and to build in an explicit contingency/fallback plan (manual override, rapid-scale trigger) for events materially larger than anything in the training history.

Worked example
Growth-style capacity questions (e.g. planning for user growth from 100k to 2M over 12 months) are a related but DISTINCT variant: at that scale of change, a pure time-series extrapolation of recent history is unreliable because the growth is driven by a step-change in the business (a new market, a new channel), not organic continuation of an existing trend, so a growth-curve or scenario-based model (grounded in comparable prior launches, if any exist) is usually more defensible than SARIMA/ETS extrapolation alone, with prediction intervals presented explicitly as scenario bands rather than a single confident number. A supply-side shock (e.g. a courier strike suddenly reducing available capacity) is the mirror-image problem: the DEMAND forecast may still be accurate, but the operational decision needs a separate supply-constraint model layered on top, since the two are not interchangeable.

Trade-offs & pitfalls
The most common mistake is validating the forecast on average-case error while the capacity decision actually depends on TAIL behavior (event days, growth inflection points, supply shocks); a model that looks excellent on an aggregate accuracy metric can still be dangerously wrong exactly when the capacity plan needs it most. Report event-day accuracy and interval coverage separately from the steady-state number, and be explicit with stakeholders about which regime (steady-state vs event-driven vs step-change growth) a given forecast is actually reliable for.