MQTT vs Polling Architecture at Scale

Back to Blog

Compare How Each Scales

In a polling architecture, a master issues a request to each device and waits for the response, cycling through a poll list. Add devices and the cycle lengthens or you add masters; add a second consumer that also needs the data and it either polls independently or reads a shared cache you now have to build. In an MQTT architecture, each device publishes its changes to a broker, and every interested consumer subscribes; the device does not know or care how many are listening.

Attribute	Polling	MQTT publish-subscribe
Who initiates	Master requests on a schedule	Device publishes on change
Load vs device count	Grows with the poll list	Grows only with actual change traffic
Load vs consumer count	Multiplies or needs a shared cache	One publish fans out to all subscribers
Bandwidth on quiet data	Full poll regardless	Near zero until a value changes
Liveness signal	A failed poll flags a dead device	Last will and keepalive flag offline
Central coupling	Master must reach every device	Devices reach one broker

MQTT decouples producers from consumers through the broker, which is what makes fan-out cheap. The mechanics are in the guides on publish-subscribe and the MQTT broker.

The catch is that MQTT moves the problems, it does not delete them. You now run and secure a broker, you design a topic hierarchy, and you decide QoS per stream. Polling keeps everything in the master with no broker to operate, at the cost of scaling load with the size of the poll list and the number of consumers. Whether that tradeoff favors MQTT depends almost entirely on scale and fan-out.

When Each One Wins

MQTT wins as the fleet grows and as more systems want the same data. If devices are numerous, spread across many networks, and behind links you do not want to poll constantly, having each device push changes to a broker is dramatically more efficient than pulling from all of them. It wins even harder when several consumers - a SCADA, a historian, an analytics pipeline - all need the stream, because one publish serves them all instead of each polling independently. Pairing it with change-driven publishing keeps the wire quiet, much like report by exception versus polling at the device level.

Polling wins when the fleet is bounded and the master's control over timing matters. A modest set of devices on a reliable network, where you want deterministic request timing and a simple mental model, is well served by polling - there is no broker to run and the failure of a poll is itself a clean liveness signal. Polling also wins where a device simply cannot publish and must be read, which is the majority of legacy Modbus and DNP3 equipment; there you poll at the edge even if you publish upstream.

The scaled architecture is usually a hybrid: poll legacy devices at an edge gateway, then publish their changes northbound over MQTT so the enterprise side scales by subscription rather than by poll. That gives you polling's device reach where you have no choice and MQTT's fan-out where the growth actually lives. The decision is per layer, not per system.

Pitfalls at Scale

The polling pitfall at scale is silent poll-cycle inflation: every device you add lengthens the cycle, and eventually the freshest data is minutes old without anyone deciding to accept that. Adding masters helps but multiplies operational surface, and bolting a second consumer onto a polling system tempts you into duplicate polling that doubles the load on the field. Watch the round-trip time in SCADA polling as the list grows, because that is where the ceiling first shows.

The MQTT pitfall at scale is treating the broker and topic design as afterthoughts. A flat or badly named topic space makes subscriptions and access control painful, oversized retained-message use bloats memory, and a single broker with no clustering becomes the fan-out bottleneck you were trying to avoid. Choosing a sane QoS per stream matters too, since QoS 2 everywhere buys ordering guarantees you rarely need at a cost you always pay. Design the topic hierarchy deliberately, as covered in the guide on MQTT topic hierarchy and wildcards.

In practice a cloud platform such as Merobix sits on the consuming side of either model - subscribing to an MQTT broker or polling devices and gateways - and presents the fleet as one set of live tags. The architecture choice is about how field data gets to that boundary efficiently at your scale, not about the platform. Poll where you must, publish where you grow, and let the change-driven path carry the fan-out.

Frequently Asked Questions