Theme Event-driven IT/OT integration
MQTT in brief
MQTT is a lightweight client/server protocol for publish/subscribe messaging. A client publishes a message to a topic. A server, commonly called a broker, matches it to subscriptions and forwards it. The producer does not need to know its consumers.
In context
This makes MQTT useful when many devices and systems exchange small events across links where bandwidth, code footprint or stability matter. Yet the protocol is a transport, not a complete information model. It can move a value efficiently without explaining what that value means.
From point-to-point links to an event flow
Imagine an energy meter publishing to site/line-2/meter-7/power. Operations, energy analytics and an alarm service can subscribe independently. A new consumer can be added without rebuilding the meter. This loose coupling is MQTT’s central advantage.
The modern choice is not between real-time data and ordered information. Sound architecture needs both.
The four decisions that shape the solution
1. Topic structure
Topics are delivery addresses, not automatically stable object identifiers. Define naming, hierarchy, versioning and which levels may be used for authorisation. Avoid embedding temporary organisational structures in a namespace expected to outlive them.
2. The payload contract
MQTT is payload-agnostic. JSON, binary data and other formats are possible, but schema, unit, timestamp, quality and source identity must be defined outside the core protocol. An information model or an established extension such as Sparkplug B can therefore matter.
3. Delivery level and lifetime
MQTT defines three QoS levels: QoS 0 is “at most once”, QoS 1 “at least once” and QoS 2 “exactly once” within the protocol delivery flow. Higher QoS requires more state and packet exchange. It does not replace idempotent processing in receiving business logic. Retained messages, session and message expiry, and Last Will also need choices based on lifetime and consequence.
4. Trust and operations
MQTT 5.0 recommends authentication, authorisation and secure communication for sensitive applications while leaving technology choices to implementations. TLS, client identities and topic permissions need certificate rotation, monitoring, capacity limits and a broker-failure plan.
When does MQTT fit?
- When producers and consumers need to evolve independently.
- When small, frequent events go to one or several recipients.
- When connections can be constrained or intermittent.
- When the team can own topic, payload and security contracts over time.
For synchronous queries, complex resource operations or large historical extracts, a REST API, query service or data platform is often the better complement. MQTT does not have to win every integration to be right where the event originates.
HubMind’s questions before a pilot
- Which stable object does every topic and payload identify?
- What happens with duplicates, gaps, stale retained values and reordering?
- Which QoS follows the consequence rather than intuition?
- Who may publish and subscribe to each topic-tree branch?
- How are schema changes and incompatible clients detected?
- How does the flow recover after network or broker failure?
HubMind’s view
MQTT is a nervous system for events, not the organisation’s memory. Connect the protocol to stable object identities, explicit data contracts and measurable governance. The event flow can then grow without dissolving its meaning.
Related concepts
Related: OPC UA, JSON, broker and Sparkplug B.
Scope and freshness
This page covers MQTT 5.0 and principles also present in MQTT 3.1.1. Reviewed 31 August 2026; review again when OASIS publishes a new major version or changes its security guidance.