Real-time data pipelines for IoT & sensor-heavy products
Wearables streaming 200Hz+ into a cloud ML pipeline with sub-100ms latency at 500+ concurrent sessions; smart gloves going from punch to insight in under 50ms. If your product lives or dies on sensor data arriving fast and never getting lost — this is the intersection I’ve specialised in.
Wearable and med-tech companies whose devices produce more data than their backend can swallow
Sports-tech and fitness products that need live, on-screen feedback from motion sensors
Industrial teams instrumenting equipment who need ingestion, storage, and alerting that scales
What you get
High-frequency ingestion
BLE 5.0, MQTT, WebSockets, and raw UDP pipelines engineered for 200Hz+ per device — with backpressure, batching, and loss handling designed in, not bolted on.
Real-time processing & ML
Stream processing that computes while data moves: joint angles, gait symmetry, force and load computed live in a clinical platform at 92%+ classification accuracy.
Time-series storage & dashboards
PostgreSQL and Redis architectures tuned for sensor workloads, feeding live dashboards for clinicians, athletes, and operators — sub-100ms end to end.
Edge & firmware integration
ESP32 firmware, edge preprocessing, and low-power BLE design — I work from the silicon to the dashboard, so nothing gets lost between vendors.
Geo & location systems
GPS pipelines with ±2m accuracy serving 1,000+ active users at <80ms query response (Apollo Golf GPS).
BLE wearables produce 200Hz+ motion data per device. Clinicians needed clinical-grade movement analytics live during sessions — with hundreds of sessions running at once.
Built
End-to-end pipeline: BLE ingestion over WebSockets/UDP, real-time kinematics ML (joint angles, gait symmetry, power, load), and role-based live dashboards, deployed on Azure.
Our backend chokes on sensor data — can you fix the existing system?
Usually, yes. Most sensor backends fail at predictable points: per-reading inserts, synchronous processing in the request path, and no backpressure. An audit typically finds the two or three bottlenecks; fixes range from batching and buffering to a targeted re-architecture of the hot path.
What throughput can this actually handle?
The reference numbers from my production systems: 200Hz+ per device sustained, 500+ concurrent sessions, sub-100ms sensor-to-dashboard latency, and <50ms data-to-insight on the fastest pipeline. Your numbers depend on payload size and processing depth — which is exactly what the architecture phase models.
Do you handle the hardware side too?
Yes — ESP32 firmware, BLE GATT design, and edge preprocessing. Owning both ends means the protocol, batching, and power budget are designed together instead of negotiated between vendors.
What happens when a device goes offline?
The pipeline is designed for it: on-device buffering, idempotent replay on reconnect, and server-side deduplication. Data loss is an engineering choice, not an accident — we decide explicitly what is buffered, for how long, and what is droppable.
Have a project in mind?
A free 30-minute call — you describe the problem, I tell you honestly whether and how I'd solve it.