Design Demand Forecasting - System Design | WinJob

Demand Forecasting Problem Framing

Retail demand forecasting is a supply-chain control surface: a 12% WAPE miss on 180k active SKUs can strand $40M/week in working capital. This section locks planner-facing forecast contract for retail and mobility demand forecasting while Amazon/Uber/Walmart interviewers listen for numbers before model names.

Quantified controls (Demand Forecasting Problem Framing)

Control	Target	Why it matters
Primary	WAPE < 8%	Guards planner-facing forecast contract under peak 180k active SKUs
Secondary	publish lag < 2h	Keeps planners from stale ERP pushes
Tertiary	override audit 100%	Human edits must beat model without silent drift

Mechanism

Every forecast row carries run_id, model_version, feature_snapshot_ts, and reconciliation_tier (SKU, store, DC). Training uses point-in-time exogenous joins: promo flags and weather only if event_ts ≤ forecast_origin. Serving never blends offline batch features computed after origin.

Failure modes unique to section 1

Partial POS outages create false zero-demand spikes unless imputed with store-level health flags.
Promo calendars applied twice (ERP + marketing feed) inflate lift and collapse WAPE after event ends.
Cold-start SKUs borrow neighbors with mismatched seasonality → transient MAPE spikes unless capped.
Multi-region clock skew shifts day boundary for mobility overlays unless normalized to store TZ.
Champion promotion without backtest on holiday holdout regresses Black Friday accuracy.

Design pressures

Pressure 1.1: shard training by category × region to bound wall-clock below 6h nightly.
Pressure 1.2: keep MinT reconciliation at publish so DC totals equal sum of stores.
Pressure 1.3: expose explain top drivers (price, promo, weather, mobility) per SKU-DC.
Pressure 1.4: gate deploy if WAPE degrades >0.3pp vs champion on rolling 8 weeks.
Pressure 1.5: planner overrides write superseding series with reason codes, not in-place edits.
Pressure 1.6: tie 180k active SKUs to inventory $ exposure for executive narrative.

Implementation slice

javaOne Dark Pro

1 public record ForecastPoint1(
2     String runId,
3     String skuId,
4     String locationId,
5     double yHat,
6     double yLo,
7     double yHi,
8     String modelVersion
9 ) {}

pythonOne Dark Pro

1 from dataclasses import dataclass
2  
3 @dataclass(frozen=True)
4 class ForecastPoint1:
5     run_id: str
6     sku_id: str
7     location_id: str
8     y_hat: float
9     y_lo: float
10     y_hi: float
11     model_version: str

typescriptOne Dark Pro

1 export interface ForecastPoint1 {
2   runId: string;
3   skuId: string;
4   locationId: string;
5   yHat: number;
6   yLo: number;
7   yHi: number;
8   modelVersion: string;
9 }

Interview signal (Demand Forecasting Problem Framing)

Close with one SLI you would dashboard in week one—WAPE < 8%—and the corrective action if it burns (widen backtest, delay promotion, or fall back to seasonal naive for affected categories).

Why interviewers care

Demand Forecasting interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Demand Forecasting Problem Framing that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Focus: planner-facing forecast contract
•Metric: WAPE < 8%
•Anchor: 180k active SKUs

1	public record ForecastPoint1(
2	String runId,
3	String skuId,
4	String locationId,
5	double yHat,
6	double yLo,
7	double yHi,
8	String modelVersion
9	) {}

1	from dataclasses import dataclass
2
3	@dataclass(frozen=True)
4	class ForecastPoint1:
5	run_id: str
6	sku_id: str
7	location_id: str
8	y_hat: float
9	y_lo: float
10	y_hi: float
11	model_version: str

1	export interface ForecastPoint1 {
2	runId: string;
3	skuId: string;
4	locationId: string;
5	yHat: number;
6	yLo: number;
7	yHi: number;
8	modelVersion: string;
9	}