Batch ML scoring fails for industrial IoT when maintenance windows are measured in minutes. This post presents an architecture using CrateDB and FastAPI to deliver real-time ML inference on live sensor data in under 20 ms. The key insight is that CrateDB's CLUSTERED BY (device_id) table design ensures per-device history queries hit a single shard regardless of cluster size, making feature retrieval — not the model — the performance bottleneck to optimize. An XGBoost classifier and Isolation Forest are combined to produce fault_probability and anomaly_score. The FastAPI service exposes four endpoints for single-device scoring, batch scoring, and fleet-wide risk views, with predictions written back to CrateDB and immediately JOINable against live sensor data in SQL. Production trigger patterns (SCADA alarms, scheduled sweeps, per-insert scoring) and their tradeoffs are also discussed.

8m read timeFrom cratedb.com
Post cover image
Table of contents
Why batch scoring fails at the point of actionArchitecture: from sensor reading to score in one HTTP callWhy CrateDB's clustering strategy determines inference latencyRunning the inference serviceThe four endpointsWhat triggers scoring in productionClosing the loop: predictions alongside live dataThe data layer is the constraint, not the modelStart here
125 Impressions