Design a ML Model Monitoring & Drift Detection

Problem statement

Design a platform that continuously observes every model in production: it logs each inference request with its feature vector, score, and model version; ingests the delayed ground-truth outcome; computes statistical distance between live input distributions and the training reference; tracks performance metrics (accuracy, F1, MSE, AUC, calibration) over time; and raises drift alerts or automatically triggers the retraining pipeline when thresholds are breached.

The defining property of this system is that it detects failure modes that ordinary service monitoring cannot see. A model can return 200 responses with p99 latency of 40 ms while its accuracy collapses, because the world changed: fraudsters change behavior, credit populations shift after a macro shock, demand patterns move after a pandemic. CMU's Software Engineering Institute states the two detection families plainly: monitor performance metrics, or monitor data distributions [[42]]. A strong design does both, plus train/serve skew, which is a pipeline bug rather than a world change.

Why this is a distributed-systems problem, not a notebook problem

At interview scale the workload is a streaming join and a statistical compute engine. Assume a fleet of 500 monitored models producing 2 billion predictions per day (about 23K events/sec average, 116K/sec at a 5x peak). Outcomes arrive minutes to weeks later (fraud chargebacks vs. click labels), so the system must join late labels to immutable prediction records at scale. Drift statistics must be computed over sliding and tumbling windows per model, per version, per feature — hundreds of features per model — and the results must be queryable, alertable, and auditable. Every component maps to classic big-data primitives: durable event backbone, stateful stream join, windowed aggregation, time-series store, object lake, scheduler, and policy engine.

Public operating baseline versus design assumptions

Public evidence shows the category is operationally real. Uber's Michelangelo covers the end-to-end workflow including 'monitor predictions' and now powers 25,000+ models [[5]], with a feature store described as processing 10 trillion feature computations daily [[26]]. Google's TFX uses TensorFlow Data Validation for continuously arriving data validation and training-serving skew detection [[7]]. Amazon SageMaker Model Monitor compares captured serving data against baseline statistics and constraints [[15]]. Meta's FBLearner Flow reported more than a million models trained and over 6 million predictions per second in 2016 [[57]]. Netflix manages hundreds of production ML applications on Metaflow with the Maestro orchestrator [[35]]. These are cited company figures; every uncited number in this answer is an explicit design assumption.

The four architectural planes

1. Capture plane: inference logger SDK/sidecar, outcome ingestion, schema validation, sampling, and priority buffering.
2. Computation plane: label joiner, windowed feature/statistics aggregator, drift detectors, performance metric evaluator.
3. Decision plane: threshold and policy engine, alert routing, dedup/hysteresis, retraining trigger orchestrator, approval gates.
4. Governance plane: model registry linkage, baselines, lineage, audit evidence, retention, compliance, and dashboards.

Keeping these planes separate lets the capture plane degrade (sampling down) without blinding the decision plane, and lets regulated models require human approval while unregulated models auto-retrain.