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.