Architecting mmWave Radar IoT & Real-Time Processing for 100k+ Devices | Justin Dang

In the Internet of Things (IoT) landscape, the real engineering challenge isn’t merely ingesting data from hardware sensors, it’s building a resilient streaming and backend architecture capable of handling hundreds of thousands of concurrent devices without crippling your databases. This article shares deep architectural insights derived from two real-world enterprise platforms that I (Justin Dang) directly designed and built: the vehicle tracking platform VTMS and the high-scale IoT ecosystem Data Realities (sensors radar Data Realities & device-go).

1. The Hardware Challenge: Decoding 60GHz mmWave Radar (FMCW)

In Data Realities, the system interfaces directly with a 60GHz mmWave Radar (FMCW) via USB Serial communication (9600 baud, 8N1). The sensor detects movement across an 8-meter depth and ±4-meter lateral range, actively tracking up to 8 concurrent targets at 200ms polling intervals.

At the edge client tier, we leverage Device Go (fs04_device) and the Web Serial API to parse raw incoming binary packet buffers:

// Binary Command Protocol:
// Request:  446208001000000000000000BE4B
// Response Packet delimiter: 0x4A
// Object Data (8 bytes/target): Object ID, Distance (0.1m), Signed X, Signed Y

Spatial coordinates are rendered directly on the browser using a Three.js 3D Visualizer, mapping real-time target movement, position trails, and predefined boundary zones (Zones A/B) with ultra-low latency.

2. Offloading Real-Time Connections: The Pushpin Architecture

When concurrent active connections scale past 100,000 devices (much like real-time GPS telemetry in VTMS), keeping stateful WebSocket or SSE connections open on a monolithic Node.js or SvelteKit backend inevitably causes memory starvation and Event Loop blockages.

We solved this by establishing a decoupled 3-tier communication pattern:

• Pushpin Proxy Layer: Holds open all client connections at the edge. By utilizing GRIP headers (Grip-Hold, Grip-Channel, Grip-Keep-Alive), backend workers can publish updates ephemerally without maintaining connection state.
• Device Go Client: Edge devices connect via lightweight HTTP/SSE (/api/device/listen) or MQTT, transmitting compressed GZIP payloads authenticated with stateless JWTs.
• Batch Publishing (500x Acceleration): Rather than publishing status events sequentially (which took 30 seconds for 100k devices), we batch MQTT messages into 1,000-device clusters, slashing update latency down to just 0.06 seconds.

3. Data Pipeline: Redis Streams to ClickHouse Columnar Store

A classic IoT anti-pattern is writing continuous telemetry streams into traditional RDBMS engines (PostgreSQL / MySQL), inevitably leading to catastrophic table locks. In both Data Realities and VTMS, we enforce strict workload isolation:

• PostgreSQL (Prisma & ZenStack): Strictly reserved for relational metadata (Device profiles, Account memberships, RBAC).
• Redis Streams & BullMQ: Operates as a high-throughput buffer to absorb backpressure and distribute ingestion tasks to asynchronous worker pools.
• ClickHouse Columnar Storage: Raw sensor logs (logs_raw) stream via Vector pods into ClickHouse. Automated Materialized Views (mv_radar_session, mv_radar_path) index the data for sub-50ms analytics across hundreds of millions of records.

4. Key Engineering Takeaways

Building scalable IoT platforms requires mastering hardware protocols, network backpressure, and database specialization. The battle-tested architectures behind VTMS and Data Realities show that intentional decoupling and event-driven pipelines are fundamental to achieving production reliability at scale.

Real-World Interface: Radar Live Preview & RDM Fleet Management

Below are live captures from the production interface of Data Realities, highlighting the Sensors IoT subsystem and Remote Device Management (RDM) architected by Justin Dang: