Design a Predictive Maintenance System — System Design Interview Practice

Interview prompt

Design a predictive-maintenance platform that ingests equipment telemetry, detects anomalies, estimates remaining useful life, and creates actionable maintenance work before failures occur.

• Separate raw timestamped telemetry, equipment and sensor metadata, feature windows, model predictions, alerts, and work orders.
• Use event-time windows and equipment partitions, handle missing or out-of-order readings, and preserve the evidence behind a prediction.
• Turn predictions into deduplicated maintenance recommendations with operator acknowledgement and feedback loops.
• Explain cold-start equipment, sensor drift, false alarms, safety escalation, offline operation, retention, and model rollback.

Requirements and scale assumptions

• Register equipment and sensors, ingest telemetry, calculate features, score failure risk and remaining life, and create work recommendations.
• Expose equipment health, anomaly evidence, prediction confidence, model version, sensor freshness, and maintenance status.
• Support acknowledgements, overrides, corrective labels, reprocessing, access control, audit history, and model evaluation.
• Target above 90% recall for critical failures at a declared false-alarm budget and keep health dashboards below 2 seconds p95.
• Ingest 1 million sensor readings per second by equipment and site partitions without losing safety-critical alerts.
• Make telemetry ingestion, feature windows, predictions, alerts, and work-order creation idempotent.
• Fall back to threshold rules and last-known health when model workers or upstream telemetry are degraded.
• Monitor 1 million assets, 100 million sensors, and 1 million readings per second across sites with intermittent connectivity.
• Partition by tenant, site, asset, sensor, and event time; isolate high-rate assets and incident bursts.
• Retain raw telemetry, feature definitions, predictions, labels, alerts, and work-order decisions under safety policy.

• Peak scale: 1M assets; 1M readings/s — Capacity assumption that drives partitioning and backpressure.
• Latency target: health p95 < 2s; critical alerts preserved — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Timestamped telemetry, equipment metadata, and acknowledged work orders are authoritative; predictions are derived.
• Async boundary: At-least-once workers — Keep Use LSTM or Transformer models for time-series, Implement survival analysis for RUL prediction, Use isolation forests for anomaly detection off the synchronous path.

Key entities

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

  Immutable predictive maintenance system input version used for reproducible training, evaluation, or replay.

• FeatureSnapshotentityId, featureSetVersion, eventTime, values, sourceWatermarks

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

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

  Audited predictive maintenance system run that records data, code, dependency, and evaluation lineage.

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

  A promotable predictive maintenance system model version with rollout state, contract, and rollback metadata.

Data flow

1. 1. Register and validate training dataThe predictive maintenance system gateway records an immutable dataset version, schema, lineage, quality status, and privacy disposition.
2. 2. Build point-in-time featuresFeature workers join predictive maintenance 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 predictive maintenance 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 predictive maintenance 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 predictive maintenance system retraining is evidence-driven rather than triggered by guesswork.

Deep dives and trade-offs

• Reproducibility and leakage preventionPin predictive maintenance 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 predictive maintenance 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 predictive maintenance 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 predictive maintenance 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.