Design a Computer Vision Quality Inspection System — System Design Interview Practice

Interview prompt

Design a production-line vision inspection system that captures synchronized high-resolution images, detects known and novel defects in real time, and sends safe disposition signals to factory automation.

• Define camera/line identity, image and part correlation, inspection version, defect taxonomy, confidence, evidence, and disposition semantics.
• Meet deterministic line latency while retaining full-resolution evidence; handle lighting drift, missing cameras, duplicate frames, and rare defects.
• Separate inference from model training, labeling, review, and factory-control integration; roll out models canary-first without stopping production.
• Explain fail-safe versus fail-open decisions, calibration, auditability, privacy, replay, observability, and degraded manual inspection.

Requirements and scale assumptions

• Capture and correlate images with part/lot/line identifiers, run versioned inference, classify defects, and persist evidence and decisions.
• Send pass/fail/quarantine signals to PLC/MES systems, expose operator review, search, metrics, and feedback for retraining.
• Support model rollback, calibration, camera replacement, evidence retention/deletion, replay, and safe operation during network or model failures.
• Meet the agreed false-negative/false-positive targets within the line decision deadline and never block production on training work.
• Inspect 1,000 parts per minute across many lines without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 100 production lines, 1,000 parts/minute, and 20 cameras per line
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 100 lines; 1k parts/minute — Capacity assumption that drives partitioning and backpressure.
• Latency target: decision p95 < 200ms; model rollout no downtime — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Captured images, inspection versions, and signed disposition records are authoritative; dashboards are derived.
• Async boundary: At-least-once workers — Keep Use object detection models (YOLO, Faster R-CNN), Implement anomaly detection with autoencoders for novel defects, Use data augmentation for rare defect types off the synchronous path.

Key entities

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

  Immutable computer vision quality inspection system input version used for reproducible training, evaluation, or replay.

• FeatureSnapshotentityId, featureSetVersion, eventTime, values, sourceWatermarks

  Point-in-time computer vision quality inspection system features with source watermarks so online and offline values can be compared.

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

  Audited computer vision quality inspection system run that records data, code, dependency, and evaluation lineage.

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

  A promotable computer vision quality inspection system model version with rollout state, contract, and rollback metadata.

Data flow

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

Deep dives and trade-offs

• Reproducibility and leakage preventionPin computer vision quality inspection 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 computer vision quality inspection 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 computer vision quality inspection 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 computer vision quality inspection 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.