Factory IoT is not the same as consumer IoT. The constraints are different: machines run 24/7, network connectivity is unreliable at the floor level, PLCs speak proprietary protocols, and downtime has direct financial cost. A Raspberry Pi running Python that works fine in a lab will misbehave when the factory Wi-Fi drops or a machine floods the bus with error codes at 1000 messages per second.
MQTT is the right protocol for shop floor telemetry. It's designed for constrained environments — tiny packet overhead, TCP-based with QoS levels, and broker-mediated so devices don't need direct connectivity to consumers. QoS 1 (at-least-once delivery) is the practical default: you accept possible duplicates in exchange for guaranteed delivery. Idempotent message handlers on the consumer side deal with the duplicates.
Topic structure matters more than most teams realize. A flat topic namespace like `machine/data` that carries all machine telemetry in the payload is an anti-pattern — it forces every subscriber to deserialize every message to filter what they need. A structured hierarchy like `factory/{site}/{machine_id}/telemetry/{metric}` lets subscribers use MQTT wildcards efficiently: `factory/kl/+/telemetry/temperature` subscribes to temperature from all machines at the KL site without receiving spindle speed or vibration data.
Go is well-suited for the broker-side ingestion pipeline. The goroutine model maps cleanly to concurrent message processing — each incoming topic can be handled by a dedicated goroutine pool. Memory footprint is low compared to JVM-based alternatives, and the compiled binary deploys trivially to edge hardware. We ran the ingestion service on ARM-based edge nodes co-located in the electrical room of each factory floor, reducing WAN traffic by aggregating and batching data before forwarding to the cloud.
InfluxDB is the right storage choice for time-series telemetry. Its data model — measurement, tag set, field set, timestamp — maps directly to machine telemetry. Tags (machine ID, site, machine type) are indexed and enable fast filtering. Fields (temperature, spindle speed, vibration) are the actual measurements. Continuous queries and retention policies let you auto-downsample high-resolution data into hourly and daily rollups, keeping storage costs under control without losing the granularity needed for anomaly detection.
The hardest problem is not the data pipeline — it's machine connectivity. CNC machines from the 1990s speak RS-232 or Modbus RTU. Newer machines speak OPC-UA. Each manufacturer's PLC has a different data model and a different set of registers. We built a thin adapter layer: one Go process per machine family that speaks the machine's native protocol and emits normalized MQTT messages. This isolates protocol complexity at the edge and keeps the cloud-side pipeline simple.