Publish/subscribe - pub/sub for short - is the messaging pattern behind MQTT, unified namespaces, and most modern IIoT. It replaced the older habit of every system asking every other system for data on a timer. Understanding pub/sub is the key to understanding why cloud-native SCADA scales the way legacy polling architectures could not. This page explains the pattern, its parts, and how it compares to polling.
What Is Publish/Subscribe? in one line: Publish/subscribe is a messaging pattern in which producers send messages to named topics without knowing who will receive them, and consumers register interest in topics to receive matching messages - all mediated by a broker. Producers and consumers are fully decoupled and never communicate directly.
A pub/sub system has three roles. Publishers produce messages and send them to a topic - a named channel like field/tank7/level - without any knowledge of who is listening. Subscribers declare interest in one or more topics and receive every message published to them. A broker (or message bus) sits in the middle, keeping track of subscriptions and routing each published message to the right subscribers.
The defining property is decoupling in three dimensions: in space (parties do not know each other's addresses), in time (a subscriber can receive a retained message published before it connected), and in synchronization (publishing does not block waiting for consumers). This is why pub/sub is often described as event-driven: data flows the moment something happens, not when someone asks.
The alternative pattern is polling: a client repeatedly asks a device 'what is your value now?' on a fixed interval. Polling is request/response and tightly coupled - the poller must know each device's address and reach it directly. With hundreds of remote sites, polling means hundreds of connections, fixed bandwidth whether or not data changed, and inbound network access to every device.
Pub/sub flips this. A device publishes only when something changes (report by exception), makes a single outbound connection to the broker, and any number of consumers get the data at once. For distributed oilfield telemetry over cellular, this is dramatically more efficient and more secure, because no inbound ports are exposed. The trade-off is that pub/sub needs a broker as shared infrastructure, and event-driven flows require more thought about state and delivery guarantees than a simple poll loop.
In industrial systems, pub/sub is most visible as MQTT with Sparkplug B, the foundation of unified namespace architectures. OPC UA also offers a pub/sub mode alongside its traditional client/server model. Within a SCADA platform itself, pub/sub often drives the internal event bus that pushes live tag updates to dashboards and alarms the instant a value changes.
A cloud SCADA benefits enormously from pub/sub: it can subscribe to a broker fed by thousands of edge devices and scale horizontally, rather than maintaining thousands of outbound poll loops. Merobix consumes MQTT and Sparkplug B pub/sub data while still polling Modbus and DNP3 devices, so operators can mix event-driven and polled sources in one platform.
In request/response (polling), a client explicitly asks a specific server for data and waits for a reply, so the two are tightly coupled. In pub/sub, publishers send to topics and subscribers receive from topics via a broker, with no direct link between them - data flows on change rather than on request.
Yes. MQTT is the most widely used industrial pub/sub protocol. Clients publish messages to topics on a broker and other clients subscribe to those topics. Sparkplug B adds a standard topic structure and payload format on top of MQTT for industrial use.
A remote device using pub/sub makes one outbound connection to a broker and publishes only when data changes, conserving cellular or satellite bandwidth and avoiding any inbound firewall openings. Polling requires reaching each device individually on a timer, consuming bandwidth even when nothing changed and exposing devices to inbound access.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.