Real-Time Telemetry Anomaly Detection Pipeline
Catching sensor anomalies in the stream, not after the fact.
SITUATION
Streaming sensor telemetry (fuel pressure, engine temperature) is noisy by nature — duplicate readings, out-of-order timestamps, and value spikes are the norm, not the exception. Catching a real anomaly inside that noise in real time, rather than after a batch job runs, is what actually matters for a monitoring system.
TASK
Build an end-to-end streaming pipeline that ingests noisy sensor telemetry, scores each reading for anomalies as it arrives, and visualizes results live — while handling the real distributed-systems problems a naive version would ignore.
THE DATA
A Python producer simulates sensor telemetry with realistic dirty-data injection: duplicate events, out-of-order timestamps, and artificial value spikes. Because readings stream through a Kafka-compatible broker to multiple consumer instances, deduplication and ordering can't be solved with a simple in-memory check — they have to hold up across restarts and multiple consumers.
ACTION
Built a Python producer emitting sensor telemetry into Redpanda (a Kafka-compatible broker), a stream processor that deduplicates events and scores each reading with a pre-trained Isolation Forest model, and a TimescaleDB sink writing clean, labeled data to a time-partitioned hypertable. An auto-provisioned Grafana dashboard refreshes every 5 seconds to visualize results live, with the whole stack orchestrated via Docker/docker-compose.
TRADE-OFFS
Deduplication needed to be both fast and actually correct across multiple consumer instances — an in-memory cache alone is fast but not durable or coordinated, and a database constraint alone is correct but too slow to check on every message. Used both: an in-memory TTL cache handles the common case quickly, with a unique database constraint as the real correctness guarantee underneath it.
DESIGN DECISIONS
Per-sensor z-scores instead of raw values
The Isolation Forest was first trained on raw sensor values (fuel pressure ~3000psi, engine temperature ~650°F) and flagged 100% of readings as anomalies — the learned baseline didn't generalize across sensors with wildly different physical units. Scoring on a rolling per-sensor z-score instead let one model generalize across sensor types.
Two-layer deduplication, not one
An in-memory TTL cache catches duplicates fast, but isn't durable or shared across consumer instances. A unique database constraint is the real correctness guarantee underneath it — the cache is a speed optimization, not the safety net.
DEPLOYMENT
Orchestrated with Docker/docker-compose (Redpanda, TimescaleDB, Grafana). The consumer explicitly handles SIGTERM/SIGINT so it leaves its Kafka consumer group cleanly on shutdown, instead of leaving a “zombie” member that stalls rebalancing for tens of seconds.
RESULT
A working demonstration of real streaming-systems judgment, not just a model in a notebook: the pipeline handles out-of-order data, deduplicates correctly across consumers, and recovers cleanly from restarts — the kind of correctness problems that only show up once data is actually moving in real time.