MQTT topics are not queues. They are hierarchical names, and subscriptions are wildcard matches over those names. That means the topic tree is a public interface: once devices publish to a shape, changing it means updating every device in the field.
A structure that scales
Lead with the thing that is most stable and most likely to be used as a filter boundary. For most deployments that is the site or tenant, then the device class, then the device identifier, then the measurement.
- site/{site}/device/{deviceId}/telemetry/temperature
- site/{site}/device/{deviceId}/status
- site/{site}/device/{deviceId}/command
Why wildcards are the risk
A subscription to # receives everything on the broker. One misconfigured client doing that will pull the entire fleet's traffic over its link. Keep wildcard subscriptions narrow, and treat broad ones as a design smell rather than a convenience.
Practical rules
- Never put device-generated identifiers in the leading segment.
- Keep the depth fixed so wildcards stay predictable.
- Use retained messages for status, not for telemetry.
- Decide the QoS level per topic, not globally — QoS 2 on high-frequency telemetry is usually a mistake.