A clean laboratory connection can hide the conditions that shape a production device system. The architecture needs an answer for duplicate messages, delayed delivery, device identity, credentials, firmware compatibility and the period when the backend cannot be reached.
Start with a small telemetry contract
Include a device identifier, event type, schema version, device timestamp, sequence or message identifier and a payload with explicit units. Version the contract before the first incompatible change is needed.
{
"schemaVersion": 1,
"deviceId": "meter-07",
"messageId": "018f...",
"observedAt": "2026-07-30T09:15:00Z",
"type": "energy.reading",
"payload": { "voltageV": 229.4 }
}Use topics as routing, not as a database
A topic hierarchy can separate environments, device groups and message classes. Authorisation should constrain what each device can publish or subscribe to. Avoid encoding every mutable business relationship into a topic name; resolve richer context in the backend.
Separate commands from telemetry
Telemetry reports observations. Commands request an action and need stronger acknowledgement, expiry and authorisation semantics. Keeping the channels distinct makes safety policies and audit history easier to reason about.
Give the edge only the responsibility it needs
Local filtering, buffering or control can keep essential behaviour available during a network interruption. But every additional edge responsibility increases update and support complexity. Choose it because latency, bandwidth or operational continuity requires it—not because edge computing sounds modern.