In the previous post, we outlined the core elements of a Unified Namespace (UNS): a central, structured, real-time data architecture that enables seamless information flow across an enterprise. But having the right architecture is only part of the equation. To truly unlock the potential of a UNS, we need the right communication protocol technology, one that supports real-time, event-driven data exchange at scale while ensuring interoperability, security, and efficiency.

In this post, we’ll explore why MQTT is the only protocol in the industry that can fully deliver on the promises of a UNS. Unlike other messaging and data exchange technologies, MQTT is uniquely suited for scalability, low-latency communication, hierarchical dynamic topic structures, and fine-grained access control, all of which are essential for an effective UNS.

Event-Driven Architecture: The Foundational Pattern for a Unified Namespace

A Unified Namespace (UNS) is not just a central repository of data—it is a real-time, dynamic representation of an entire enterprise’s operational and business state. To achieve this, it must be built on an event-driven architecture (EDA), a foundational pattern that enables low-latency, scalable, and decoupled data exchange.

Traditional system architectures often rely on request-response mechanisms, where applications periodically query databases or APIs for updates. This approach introduces latency, inefficiencies, and rigid point-to-point integrations, making it very difficult to scale as enterprises grow.

In contrast, an event-driven architecture ensures that data is pushed in real time as soon as it becomes available, allowing systems to react instantly without unnecessary polling or delays.

At the core of EDA is the publish-subscribe model, where producers publish data once, and multiple consumers can subscribe to the topics they need (one-to-many), without the producers having to know who the consumers are. This architecture approach is highly distributed across the enterprise and provides a loose coupling that is critical for ensuring that the UNS can support thousands of devices, applications, and services without creating a tightly bound, unmanageable infrastructure.

By implementing EDA as a foundational pattern, a UNS supports:

Scalability & Performance: Handling millions of messages per second without performance bottlenecks.
Real-time Data Flow: Delivering data the moment an event occurs, without waiting for scheduled polling.
System Decoupling: Allowing new applications to subscribe to relevant data streams without modifying existing systems.
Flexibility and Extensibility: Enabling seamless integration of new technologies, from IoT devices to AI-driven analytics.
Dynamic Data Ingestion & Processing: Different systems (OT, IT, Business Intelligence, etc.) can consume and react to relevant events as needed.
Resilience & Fault Tolerance: An EDA enables loosely coupled systems, meaning failures in one service do not bring down the entire architecture.
Improved Data Governance & Security: With fine-grained access control on topics and message payloads, security policies can be dynamically enforced.
UNS as a Vendor-Neutral Layer: A true UNS should not lock data within specific platforms—it should support any device, cloud, or application that needs access.

MQTT is Best-in-Class for a UNS

MQTT is the best choice for the central data hub technology in a Unified Namespace because it was designed for real-time, event-driven communication, scalability, dynamic topic structure, lightweight nature, and robust security features. This makes MQTT the only protocol that fully delivers on the promises of a UNS as it meets all the key requirements of a UNS, making it ideal for handling millions of devices and messages in large, complex enterprises while ensuring low-latency communication and efficient data management. Its flexibility and ease of implementation further enhance its suitability for a wide range of industries and applications:

Centralized data communication: The MQTT broker acts as a central hub for data exchange.
Edge-driven data propagation: Devices push data changes directly into the UNS.
Push-based messaging with low latencies and real-time capabilities in stateful sessions
Flexible, dynamic Topics:
- Millions of hierarchically structured topics
- Flexible Topic-Based Filtering
Dynamic scaling to:
- Millions of apps/devices
- Hundreds of thousands of messages per second.
Highly flexible message payload
Dynamic access control fine-grained on topic level, including pub/sub restrictions
Quality of Service (QoS) levels: assurance for message delivery
Extremely lightweight and easy to implement
MQTT is open: It is not controlled by any single vendor, meaning companies can integrate different systems, devices, and applications without a proprietary lock-in.
MQTT’s open nature means: Edge Devices, SCADA, PLCs, ERP, MES, AI/ML systems, and cloud platforms can all participate in the ecosystem.
"Open Ecosystem": This pattern is foundational for UNS success, and MQTT plays a key role in making it happen.

Industry Standard

Open protocol developed by IBM in the late 1990s
IBM opened the MQTT protocol in 2010 by making the specification publicly available and contributing it to the Eclipse Foundation.
Standardized by OASIS (Organization for the Advancement of Structured Information Standards) in 2014
Official ISO standard (ISO/IEC 20922) since 2016.

The Role of MQTT

In addition to the fundamental concepts (client/broker, publish/subscribe), MQTT has additional highly relevant features such as Quality of Service, Retained Messages, Persistent Sessions, Last Will and Testament, and more.

MQTT Core Elements

MQTT Broker: The MQTT broker is the central server responsible for managing messages. It receives all messages from publishers and forwards them to subscribers based on the topics they have subscribed to.

MQTT Clients:

Publisher: A publisher is a device or application that sends messages to the broker, typically containing information from sensors or other data sources.
Subscriber: A subscriber is a device or application that registers with the broker for a specific topic and receives messages related to that topic.
Dual Functionality: MQTT clients can act as both publishers and subscribers simultaneously, meaning they can send information while also reacting to incoming data (e.g., control commands, parameter changes).

MQTT Topics: In MQTT, every message is assigned to a topic. Topics serve as filters that determine which messages are forwarded to which subscribers.

Message Queues vs. MQTT: Key Differences

The name MQTT and the question of whether the protocol is implemented as a message queue often cause confusion. MQTT originates from IBM’s MQSeries product and does not stand for "Message Queue." Therefore, it is incorrect to expand MQTT as "Message Queuing Telemetry Transport"—the correct term is "MQ Telemetry Transport."

Since 2013, it has become standard practice to treat "MQTT" as a proper name rather than an acronym. Although the working group is still officially called the "OASIS Message Queuing Telemetry Transport Technical Committee," it was decided that "MQTT should not be standing for anything."

A message queue stores messages until they are consumed. When using a message queue, each incoming message is kept in the queue until a client (often referred to as a consumer) retrieves it. If no client picks up the message, it remains in the queue, waiting to be processed. In a traditional message queue, every message is expected to be processed by at least one client. This differs from MQTT, where a message can go unprocessed if no client has subscribed to the corresponding topic at the time of publishing.

A Message is Consumed by Only One Client

Another key difference is that, in a traditional message queue, each message is typically processed by a single consumer. The workload is distributed among all consumers connected to the queue. In contrast, MQTT follows a publish-subscribe model, where every subscriber to a topic receives the message. This behavior is similar to subscribing to an email newsletter (in contrast to a direct 1:1 sender/receiver relationship), where multiple subscribers receive the same message either simultaneously or at different times.

Traditional Message Queues Require Explicit Creation

Message queues are named and must be explicitly created, making them much less flexible than MQTT topics. Before using a queue, it must be manually defined with a separate command. Only after it has been named and created can messages be published or retrieved. In contrast, MQTT topics are highly dynamic: they are created instantly without requiring prior setup.

However, some systems provide an auto-create option, but auto-creation of topics and queues in traditional messaging systems introduces several challenges compared to more dynamic approaches. Automatically generated queues often require metadata storage, resource allocation, and indexing, leading to increased memory and processing overhead. This can slow down scalability, particularly when dealing with a large number of dynamically created queues. Unlike systems designed for true on-the-fly topic usage like MQTT, many message queues require additional configuration for access control, security enforcement, and message retention, making management more complex.

Dynamic MQTT Topics and Role-Based Access Control (RBAC)

Depending on the broker’s implementation, dynamic MQTT topics can also be leveraged to implement flexible Role-Based Access Control (RBAC), enhancing both security and message-handling flexibility. RBAC assigns fine-grained permissions to users and devices based on roles instead of granting access to individual users or clients directly. By applying RBAC at the topic level, access control is dynamically aligned with the structure of the MQTT topics used for communication. However, it is important to note that RBAC is not defined within the MQTT protocol itself, but rather as an additional feature provided by specific broker implementations.

MQTT Characteristics & Build-in Features

Lightweight Design

When MQTT is described as "lightweight," it means that the protocol is very simple, efficient, and resource-friendly. MQTT was specifically designed to transmit small data packets over unreliable networks with limited bandwidth and intermittent connectivity. Compared to a lot of other protocols, MQTT has a small code footprint, minimal overhead, and low power consumption, making it ideal for constrained environments.

MQTT uses a binary message format for communication between clients and brokers. This makes it highly efficient in terms of bandwidth and storage usage, particularly in low-bandwidth networks or cellular communication scenarios.

Another key aspect of MQTT's lightweight nature is its ease of implementation on the client side. MQTT was designed with usability in mind, ensuring that even resource-constrained devices can integrate it with minimal effort. Thanks to its minimal packet overhead, MQTT is well-suited for devices with limited processing power, memory, and battery life, such as sensors and IoT devices.

MQTT Topics

In MQTT, a topic refers to a UTF-8 string that is used to filter messages for a connected client. A topic consists of one or more levels, separated by a forward slash “/”, which acts as the topic level separator.

Compared to a traditional message queue, MQTT topics are extremely lightweight. A client does not need to create or declare a topic before publishing or subscribing to it. The broker automatically accepts any valid topic without requiring prior initialization.

Topic Wildcards

Single-Level Wildcard: +

The single-level wildcard is represented by the plus symbol (+) and allows for the substitution of a single topic level. When subscribing to a topic using this wildcard, any topic that contains any string in place of the wildcard will match.

Single-Level Wildcard: + For example, a subscription to myhome/groundfloor/+/temperature could match the following topics:

Example of MQTT Wildcard Implementation

Multi-Level Wildcard: #

The multi-level wildcard covers multiple topic levels. It is represented by the hash symbol (#) and must be placed at the end of a topic, preceded by a forward slash.

When a client subscribes to a topic using a multi-level wildcard, it will receive all messages from topics that match the pattern before the wildcard, regardless of the topic depth or length.

Multi-Level Wildcard: For example, subscribing to myhome/# would match:

subscribing example If a client subscribes using # alone, it will receive all messages sent to the MQTT broker, regardless of topic.

MQTT Payload

In MQTT, the term "payload" refers to the actual content or data of a message that is transmitted between a client and an MQTT broker. MQTT is payload-agnostic, meaning it does not enforce any specific format for the data contained within a message's payload. This allows the payload to carry plain text, binary data, or structured formats such as JSON, XML, or any other data type that both the sender and receiver can interpret and process. This flexibility makes MQTT highly adaptable for a wide range of applications and systems.

The maximum payload size in an MQTT message is theoretically limited to 256 MB by the MQTT specification. However, in practice, the actual maximum payload size depends on the limitations of the broker, network bandwidth, and the resources of the devices involved. For resource-constrained devices or networks with limited bandwidth, it is recommended to use smaller payloads to optimize efficiency and performance.

MQTT is "Stateful"!

MQTT is a stateful protocol, meaning that the communication state between a client and an MQTT broker is maintained throughout the duration of a network session. This key characteristic allows MQTT to provide highly reliable message delivery.

This reliability is achieved through several mechanisms and features defined by the protocol, including:

Quality of Service (QoS) Levels
Persistent Sessions
Client Keep-Alive
Last Will and Testament (LWT) (or simply "Will")
Retained Messages

These features ensure that messages are delivered reliably, even in cases of network disruptions, client disconnections, or unexpected failures.

QoS (Quality of Service) in MQTT

MQTT supports three levels of Quality of Service (QoS): QoS 0, QoS 1, and QoS 2. Each level defines how messages are delivered and acknowledged, allowing applications to balance reliability, latency, and network efficiency based on their specific needs.

QoS 0 – "At Most Once" Delivery

QoS 0 provides a best-effort delivery mechanism where messages are sent without acknowledgment and may be lost if delivery fails. This is the lowest QoS level and is typically used in situations where occasional message loss is acceptable, or the message is not critical.

Example use case: Sensor data streaming, where minor data loss does not significantly impact overall results.

QoS 1 – "At Least Once" Delivery

QoS 1 ensures that messages are delivered at least once but may be duplicated. When a publisher sends a message, it waits for an acknowledgment from the broker. If no acknowledgment is received within a certain time, the publisher resends the message, which could result in duplicate deliveries.

This QoS level is used in scenarios where message loss is unacceptable, but duplicate messages can be handled by the application.

Example use case: Command messages to devices, where missing a command could have serious consequences, but handling duplicate commands is possible.

QoS 2 – "Exactly Once" Delivery

QoS 2 ensures that a message is delivered exactly once, without duplication. It achieves this through a two-step acknowledgment process between the publisher and broker. The broker stores the message until the subscriber has fully received and confirmed it, preventing any duplication or loss.

This is the highest level of reliability in MQTT but also introduces additional overhead, requiring more processing time and network traffic. It is used in situations where message loss or duplication is entirely unacceptable.

Example use case: Financial transactions or emergency alerts, where duplicate or lost messages could have severe consequences.

Choosing the Right QoS Level

Higher QoS levels provide better reliability but come at the cost of increased latency, network traffic, and resource consumption. It is crucial to select the appropriate QoS level based on the specific requirements of the application to balance performance and reliability effectively.

For more details on MQTT Quality of Service, visit:

Persistent Sessions

MQTT allows clients to enable a "Persistent Session," meaning the broker retains session-related information even if the connection is lost. This includes subscriptions and undelivered messages that were sent with QoS 1 or QoS 2. When the client reconnects, the broker identifies the session using the mandatory Client ID and seamlessly resumes communication. Learn more on Persistent Sessions.

Client Keep-Alive

The Keep-Alive mechanism helps ensure that the connection between the client and the broker remains active. Clients send periodic PINGREQ messages, to which the broker responds with PINGRESP. If no response is received within the defined interval, the client assumes that the connection is lost and can take action, such as attempting to reconnect. Learn more on Client Keep-Alive.

Retained Messages

An MQTT broker can store the last message for a topic, even after it has already been delivered to all current subscribers. When a new subscriber joins the topic, it immediately receives the most recently stored message, ensuring that important information is available even if the subscription occurs after the original message was published. Learn more on Retained Messages.

Last Will and Testament (LWT)

The Last Will and Testament (LWT) feature in MQTT allows clients to notify others of unexpected disconnections. When a client connects to a broker, it can include a Last Will message in the CONNECT packet. This message follows the same structure as a regular MQTT message, including a topic, retained flag, QoS level, and payload.

The broker stores the LWT message until it detects an unexpected disconnection. If the client disconnects abruptly, the broker publishes the Last Will message to all subscribers of the designated topic, informing them of the client's disconnection. However, if the client gracefully disconnects using the DISCONNECT message, the broker discards the stored LWT message. Learn more on the Last Will and Testament.

Unlocking the Potential of UNS with MQTT—Is It Enough?

MQTT isn't just another messaging protocol—it is the only protocol that meets the critical requirements of a Unified Namespace. With its lightweight, event-driven communication model, flexible topic structure, and scalability, MQTT provides the foundation for organizations to unify their operational and business data in real-time. Without it, the UNS vision simply cannot be fully realized.

But while MQTT is the best protocol for the job, the industry is still struggling with the complexity of actually building and maintaining an effective UNS at scale. Many organizations find that existing solutions fall short, lacking the enterprise-grade capabilities needed to truly harness the power of real-time data.

So what’s missing? In the next post in this series, we’ll explore why the industry needs a better solution for building a UNS—one that goes beyond just connectivity and delivers the control, governance, and intelligence required to unlock its full potential. Also, read our blog, Beyond MQTT: The Fit and Limitations of Other Technologies in a UNS, to explore why MQTT is the only protocol that fully enables a scalable and real-time Unified Namespace (UNS), ensuring seamless data exchange at scale.

Why MQTT is Critical for Building a Unified Namespace