Design a Demand Forecasting System — System Design Interview Practice

Interview prompt

Design an ML demand-forecasting platform that predicts daily, weekly, and monthly demand across thousands of SKUs and locations while handling seasonality, promotions, stockouts, and external signals.

• Version sales, inventory, pricing, promotion, calendar, weather, and external features with an explicit data-cutoff time.
• Train global and SKU-level candidates, reconcile store-region-national forecasts, and prevent future information leaking into features.
• Serve a versioned forecast snapshot quickly while training, backtesting, and late data correction remain asynchronous.
• Explain stockout censoring, cold-start SKUs, uncertainty intervals, overrides, drift, approval, and reproducibility.

Requirements and scale assumptions

• Ingest demand and feature data, define forecast horizons and hierarchies, train candidates, and publish approved forecasts.
• Query forecasts, confidence intervals, model version, feature cutoff, backtest metrics, and manual overrides.
• Support backfills, corrections, scenario forecasts, access controls, lineage, retraining schedules, and export.
• Target MAPE below 15% on agreed segments while reporting bias, coverage, and error by horizon and hierarchy.
• Train thousands of series in parallel without allowing one large category or backfill to starve daily publication.
• Make feature snapshots, training runs, model promotion, and forecast publication idempotent and reproducible.
• Serve the last approved forecast with an explicit stale marker when feature feeds or training workers fail.
• Forecast 100,000 SKU-location series across daily, weekly, and monthly horizons.
• Partition training by product and geography, isolate high-volume series, and keep feature windows bounded.
• Retain feature snapshots, labels, forecasts, model artifacts, overrides, and evaluation evidence for replay.

• Peak scale: Automate model selection per time-series — Capacity assumption that drives partitioning and backpressure.
• Latency target: Forecast accuracy (MAPE) below 15% — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The source of truth is Forecast demand at daily, weekly, and monthly levels; Handle hierarchical forecasting (store, region, national).
• Async boundary: At-least-once workers — Keep Use DeepAR or Temporal Fusion Transformer for global models, Implement hierarchical reconciliation (top-down, bottom-up), Use cross-learning across similar products off the synchronous path.

Key entities

• DatasetVersiondatasetId, version, schemaHash, qualityStatus, lineage, createdAt

  Immutable demand forecasting system input version used for reproducible training, evaluation, or replay.

• FeatureSnapshotentityId, featureSetVersion, eventTime, values, sourceWatermarks

  Point-in-time demand forecasting system features with source watermarks so online and offline values can be compared.

• TrainingRunrunId, datasetVersion, codeVersion, metrics, artifactUri, status

  Audited demand forecasting system run that records data, code, dependency, and evaluation lineage.

• ModelVersionmodelId, version, stage, schema, qualityGates, endpoint

  A promotable demand forecasting system model version with rollout state, contract, and rollback metadata.

Data flow

1. 1. Register and validate training dataThe demand forecasting system gateway records an immutable dataset version, schema, lineage, quality status, and privacy disposition.
2. 2. Build point-in-time featuresFeature workers join demand forecasting system inputs using event-time watermarks, prevent leakage, and publish the same feature contract for training and serving.
3. 3. Train and evaluate asynchronouslyThe orchestrator schedules demand forecasting system runs with checkpointed artifacts, reproducible environments, and metrics tied to the exact input versions.
4. 4. Gate and serve a model versionA registry compares demand forecasting system quality, bias, safety, and compatibility gates before canary or production rollout with an immediate rollback pointer.
5. 5. Monitor drift and learn from feedbackOnline inference records latency, errors, drift, and delayed labels so demand forecasting system retraining is evidence-driven rather than triggered by guesswork.

Deep dives and trade-offs

• Reproducibility and leakage preventionPin demand forecasting system data, feature, code, dependency, and model versions for every run. Use point-in-time joins and quarantine failed quality or privacy checks before training. Keep raw inputs and artifacts immutable so a result can be replayed after a dependency changes.
• Safe promotion and serving contractsSeparate demand forecasting system model registration from deployment and require signed artifacts plus schema compatibility. Use shadow traffic, canaries, rollback pointers, and per-version latency/error budgets. Return model version and feature freshness so clients can explain or reproduce a prediction.
• Drift, feedback, and costMeasure feature drift, prediction drift, label delay, and segment-level quality for demand forecasting system rather than only aggregate accuracy. Sample expensive inference and cap retraining concurrency with an explicit GPU or compute budget. Keep human corrections and delayed labels linked to the original prediction and model version.
• Batch versus online featuresPrefer a shared feature contract with batch backfills and a low-latency online serving path for decisions that need freshness. Two independently defined transformations create training-serving skew and hard-to-debug regressions.
• Synchronous versus asynchronous inferenceKeep interactive demand forecasting system inference synchronous within a strict budget and queue large or expensive jobs. A request path that waits for model loading, enrichment, or retraining turns downstream slowness into an outage.
• Global model versus segment modelsStart with one versioned model and add segment-specific models only when quality or policy evidence justifies the operational cost. Many simultaneously active versions multiply monitoring, rollback, and data-lineage burden.