Standalone MQTT servers vs. clustered MQTT server topologies in OT systems

As organizations scale industrial data infrastructure, they eventually face a design decision: how should MQTT servers be deployed to support reliability, performance, and high availability?

In many architectures, clustering is presented as an answer.

Clustering is when multiple MQTT servers are grouped together and exposed as a single endpoint, with the goal of simplifying scalability and infrastructure management.

That approach may be attractive in some IT environments. But for industrial command and control, the priority is different.

In OT systems, the most important requirement isn’t elastic scaling, it’s deterministic, trustworthy data delivery.

When industrial systems depend on real-time device state, command messages, and process variables, messages must be delivered in order. If they are not, operators and applications may act on stale or incorrect information.

In this article, we’ll break down the challenges organizations are facing, where clustering falls short, and a better approach for industrial systems.

In OT systems, message order matters

Industrial devices constantly publish information about the current state of the physical world:

  • valve states
  • machine status
  • temperature data
  • pressure data

If messages arrive out of order, systems may receive stale data after newer updates.

For example, imagine a process where a control system checks whether a valve is open before transferring fluid into a storage tank.

If an older message arrives after a newer one, the system might believe the valve is open when it’s actually closed. It would continue pumping fluid, causing a spill.

In these environments, the consuming application needs to know that the data it receives reflects the latest known good state of the system.

If messages arrive out of order, that assumption breaks down.

In an industrial environment, that isn’t just a data issue. It can become an operational issue.

This is why in-order delivery is a hard requirement for OT command and control systems.

The ordering problem with clustered MQTT topologies

A clustered MQTT topology groups multiple servers together behind a single logical endpoint.

Conceptually, it looks like this:

Clustered topology

From the outside, the cluster appears to be a single system. Internally, however, messages are processed by multiple servers within the cluster.

When messages enter the cluster, they may be handled by different nodes. Each node processes and forwards messages independently, and the timing of those operations isn’t guaranteed to be identical.

Because of this, messages that were originally published in sequence can take different internal paths through the cluster. When those messages are delivered to subscribers on the output side, they may arrive in a different order than they were published.

For example:

Published by device:

1 → 2 → 3 → 4

Delivered to subscriber:

1 → 3 → 2 → 4

The exact reason this happens can vary between implementations, but the outcome is what matters.

If a clustered MQTT implementation cannot guarantee that messages leave the system in the same order they were published, it introduces risk for OT command and control systems.

In industrial environments, where device state and command messages must be processed deterministically, out-of-order delivery is a serious problem.

MQTT Sparkplug reordering can help…but there are trade-offs

In MQTT Sparkplug systems, the host application may try to compensate for out-of-order delivery by buffering and reordering messages before they are passed into the OT control layer.

That can help restore order, but it does not solve the underlying problem. Instead, it shifts the burden downstream and introduces additional risks.

It can impact your OT data Service Level Agreement (SLA)

If the host application has to wait for missing messages before it can restore order, delivery latency increases.

For example, if your OT data SLA requires data to arrive within 3 seconds, but the application spends 15 seconds buffering and reordering messages, you have already missed the SLA. The data may eventually be corrected, but it’s no longer arriving in the time window the system requires.

It can increase memory and processing demands

To reorder messages, the MQTT Sparkplug host application has to buffer out-of-order messages in memory while waiting for the missing message it needs to complete the sequence.

That increases memory consumption and shifts additional processing overhead onto the host application server.

It can still result in data loss

If the host application cannot reorder the messages in time, it may discard the buffered out-of-order messages and request a Sparkplug Rebirth.

At that point, the system has already lost continuity, and real-time data loss has occurred.

Rebirth requests can make the problem worse

Servicing Sparkplug Rebirth requests can compound the issue. A rebirth introduces another large set of MQTT Sparkplug messages, and if the clustered MQTT servers again fail to deliver those messages in order, the host application can fall back into the same buffering and recovery cycle.

In practice, this can create an unstable loop of reordering, rebirth requests, and additional strain on the OT system.

A better fit for OT: Multiple standalone MQTT servers

For industrial environments, a simpler topology is often the better one.

Instead of grouping MQTT servers into a cluster, organizations can deploy multiple standalone servers and allow clients to connect to one of several available endpoints.

Conceptually, that looks like this:

In this model:

  • some clients may publish to Server A
  • others may publish to Server B
  • others may publish to Server C

Each server operates independently. If one server goes offline, clients can fail over to another available server.

This approach offers several advantages for OT systems:

  • ordered delivery is easier to preserve
  • system behavior is easier to understand
  • failover is straightforward
  • troubleshooting is simpler
  • the topology is more transparent

Just as importantly, this model avoids forcing all traffic through a single logical channel.

Fewer single points of failure

Clustered topologies tend to introduce additional single points of failure.

When traffic enters and exits through a single logical path, a disruption at that point can affect the entire system. A blip does not impact one-third of traffic. It can impact everything.

With standalone servers, the risk is distributed.

If Server C goes down:

  • Server A and B continue operating
  • only the clients using C need to fail over
  • the entire OT system does not have to rebirth at once

That is a much simpler and more resilient failure model.

In industrial environments, simplicity matters. It’s easier to understand what failed and how the system recovers.

What about scale?

One reason clustering is often promoted is scalability. The assumption is that a clustered topology is necessary to support very large message volumes.

But in most OT deployments, that assumption does not hold up.

The reality is that most industrial environments do not need massive, dynamically scaling broker infrastructure. They need a system that is:

  • properly sized
  • highly available
  • geographically resilient if needed
  • predictable under failure conditions

For many industrial deployments, a single well-sized MQTT server can handle the full workload. Adding two or three standalone servers provides redundancy, high availability, and regional separation without introducing the complexity of a clustered topology.

Reliability matters more than architectural complexity

There isn’t anything inherently impressive about complexity in industrial infrastructure.

If a topology introduces more moving parts, more recovery logic, more buffering, and more opportunities for out-of-order delivery, it’s worth asking whether that complexity is solving a real OT problem, or just borrowing patterns from IT that do not belong in command and control systems.

For industrial MQTT deployments, the goal should be clear:

  • deliver data reliably
  • preserve the correct device state
  • avoid unnecessary single points of failure
  • keep the system understandable under load and during failure

That is why standalone MQTT servers are often the better fit for OT command and control.

In these environments, the question isn’t whether the infrastructure looks modern on paper. The question is whether the data can be trusted when it reaches the system that depends on it.

Closing thought

For OT command and control, message delivery isn’t just about throughput. It’s about order, reliability, and trust.

A simpler architecture with multiple standalone MQTT servers can provide high availability and resilience without the operational downsides that clustered implementations may introduce.

Sometimes the best industrial architecture isn’t the most complex one.

It’s the one that behaves predictably when it matters most.