MQTT Broker Redundancy and High Availability: Complete Guide

Once your MQTT deployment matters — because it carries production telemetry, or controls physical equipment, or supports customers who expect uptime — a single broker becomes a liability. If that one broker fails, the entire system stops moving messages. For deployments where this is unacceptable, you need redundancy: multiple brokers configured so that the failure of any single one does not stop the flow of messages.

The problem is that MQTT redundancy is more nuanced than it looks. MQTT is a stateful protocol with sessions, retained messages, in-flight QoS acknowledgements, and persistent client connections. A “clustered” broker is not automatically a redundant broker in the way a stateless HTTP service is. Vendor documentation on this topic is often misleading, focusing on the vendor’s specific product without honestly comparing patterns. And the client side of the story is at least as important as the broker side — client-side reconnection strategy is what actually turns broker redundancy into real availability.

This article covers all the main MQTT broker redundancy patterns — clustering, bridging, active/passive failover, load balancing, and Sparkplug primary host patterns — honestly, and gives concrete broker recommendations for each. It is a general reference: applicable to industrial, cloud, and enterprise deployments, with specifics for each where they differ.

Redundancy patterns at a glance

Pattern	Model	Client experience	Consistency	Best for
Single-broker (no redundancy)	One broker, no failover	Total outage on broker failure	N/A	Development, small deployments
Clustering	Multiple broker nodes sharing state, appearing as one	Transparent	Eventually consistent, complex	Cloud/enterprise scale
Bridging	Independent brokers connected by message forwarding	Manual switchover	Loose (topic-scoped)	Multi-site, edge-to-cloud
Active/passive failover	One live broker, standby ready to take over	Reconnect on failover	State copy required	Simple two-node HA
Load-balanced brokers	Multiple identical brokers behind a load balancer	Reconnect on failure	Session-dependent	Stateless-workload deployments
Sparkplug primary host	Multiple broker paths, application-level state	Reconnect + rebirth	Application-managed	Industrial IoT with Sparkplug B

The rest of this article walks through each pattern in depth, explains where the tradeoffs are, and gives concrete recommendations for which broker fits which pattern.

Why MQTT redundancy is not like HTTP redundancy

Before diving into patterns, it is worth being explicit about what makes MQTT redundancy harder than most people expect.

MQTT is stateful. Every connected client has a session state on the broker: its subscriptions, its queued messages for QoS 1 and 2, its in-flight acknowledgements. A “replacement” broker cannot just accept the client’s next request; it needs the client’s prior state, or it needs the client to accept starting fresh.

Persistent connections change failover behavior. HTTP requests are independent. If one HTTP server fails mid-request, the client retries against another server and life goes on. In MQTT, the connection itself is what carries state. Failover means the client explicitly reconnects, potentially to a different broker, and the two must agree on session state (or agree to start over).

Retained messages and in-flight QoS messages need special handling. A message published as retained on Broker A does not automatically appear on Broker B. A QoS 2 publish that was mid-handshake when Broker A failed is in an ambiguous state — did it get delivered or not? Each redundancy pattern handles these differently, and some handle them poorly.

The client side is half the story. No broker redundancy pattern works unless clients know how to reconnect intelligently. Reconnection back-off, primary/secondary broker lists, session resumption behavior, and handling of QoS state during failover are all client-side concerns that determine whether “broker redundancy” translates to actual availability.

Understanding these upfront makes the individual patterns much easier to evaluate. Every pattern below is a specific set of tradeoffs across these dimensions.

Before choosing a pattern: what MQTT redundancy cannot fix

Before evaluating any of the redundancy patterns, one architectural principle needs to be stated clearly, because it determines whether MQTT belongs in your deployment at all: an MQTT broker should never be part of a real-time control loop.

This is a foundational rule in industrial control systems, and it matters for redundancy discussions because no amount of broker HA can fix a fundamentally wrong architecture. MQTT is not a real-time protocol. Even in the best case, an MQTT round-trip involves TCP transmission, broker processing, subscription matching, and delivery to subscribers, with latency measured in milliseconds to tens of milliseconds. During a broker failover event, that latency can extend to seconds. Under a network partition, it can extend to minutes. This is fine for the applications MQTT was designed for; it is unacceptable for anything that must respond deterministically within a fixed time budget.

What belongs on the PLC:

• Safety interlocks and safety-instrumented functions (per IEC 61511).
• Emergency stop logic and equipment protection.
• Closed-loop process control (PID loops, motion control, sequencing).
• Anything with a hard real-time deadline measured in single-digit milliseconds.
• Anything whose failure could cause physical harm, equipment damage, or process upset.

What MQTT is well-suited for:

• Telemetry — sensor readings, process values, machine status flowing upward for monitoring.
• Historian and archival data feeds.
• Alarm annunciation and event logging to enterprise systems.
• SCADA-to-IT integration (delivering OT data to MES, ERP, data lakes, analytics platforms).
• Configuration commands and non-time-critical setpoint changes (with local PLC validation).
• Dashboard and human-machine interface (HMI) updates where sub-second latency is acceptable.

The right architecture separates these layers cleanly: PLCs handle deterministic control and safety at the plant floor, and MQTT carries the resulting data upward for enterprise integration. The two layers communicate at defined boundaries (typically OPC UA or direct PLC-to-broker bridges), but they never share the same responsibilities.

This separation is what makes system resilience actually work. When the MQTT broker fails, the PLCs keep running the process safely because they never depended on the broker for control. When the redundancy patterns below fail — and every architecture has failure modes — the plant floor keeps operating because the critical loops were never on the MQTT side of the boundary.

A useful heuristic: if your first thought about MQTT broker redundancy is “we need zero downtime because the plant will trip,” the real problem is not the broker’s HA architecture. The real problem is that the plant’s safety and control depend on the broker. Fix that first, then evaluate broker HA at the appropriate service level for what MQTT is actually carrying: important operational data, but not the control signals that keep equipment running.

The redundancy patterns below all assume MQTT is being used within this correct architectural boundary. If you find yourself justifying extreme HA measures because “the broker cannot go down,” it is worth asking whether the deployment is asking MQTT to do something it was not designed for.

Pattern 1: Broker clustering

Clustering is the pattern most people mean when they say “MQTT high availability.” A cluster is a group of broker nodes that share state and appear to clients as a single logical broker. When a client connects, it can hit any node in the cluster; the cluster distributes routing state, subscriptions, and (usually) retained messages across nodes.

How clustering works

Clustered MQTT brokers use various coordination mechanisms — masterless gossip, distributed consensus, shared storage — to propagate state between nodes. A subscription created on Node A is visible on Node B; a retained message published to Node A can be delivered to a subscriber on Node C.

The client experience is designed to be transparent. The client connects to a cluster endpoint (typically a load balancer or DNS name that resolves to any node), and does not need to know which specific node it hit. On node failure, the load balancer redirects new connections to a surviving node; the client’s existing connection breaks and reconnects.

What clustering does well

• Horizontal scale. A cluster of N nodes can handle N times the connections of a single node (or close to it). This is what makes clustering the right choice for large deployments.
• Fault tolerance. Losing one node in a cluster of three or more does not stop the cluster from operating.
• Consistent view. Clients on different nodes can see the same subscriptions, retained messages, and routing state.

What clustering does not do

• Guarantee zero message loss. In-flight QoS 1 and 2 messages during a node failure may need to be re-sent by the client, and the specific semantics depend on the broker’s clustering implementation.
• Simplify operations. A cluster is more complex to run than a single broker. Configuration, network partitioning, split-brain handling, and node recovery are all real operational concerns.
• Cost nothing. Some open-source clustering implementations require a license file even in the “free” tier (EMQX v5.9+ under BSL 1.1), or are enterprise-only (HiveMQ). Only VerneMQ offers native clustering under a permissive Apache 2.0 source license without commercial subscription for the source itself.

Broker recommendations for clustering

• EMQX — the standard choice for large-scale MQTT clustering. Masterless architecture, tested to 100+ million concurrent connections, mature clustering implementation. Note the BSL 1.1 licensing constraint from v5.9.0 onward: clustering more than one node requires a license file even in the free tier.
• HiveMQ Enterprise — enterprise-grade clustering with strong operational tooling. HiveMQ CE does not include clustering.
• VerneMQ — masterless clustering with Apache 2.0 source licensing. Historical reliability concerns around network splits with its Plumtree architecture; research current status carefully for your intended scale.
• Mosquitto — does not support native clustering. Do not use Mosquitto if you need this pattern; use bridging instead.

Pattern 2: Broker bridging

Bridging is a different pattern that is often confused with clustering. In bridging, multiple independent brokers are connected by MQTT bridges — one broker acts as a client of another and forwards specific topics between them. Each broker maintains its own sessions, its own retained messages, and its own state independently.

How bridging works

A bridge is a persistent MQTT connection from one broker (the local) to another (the remote), configured to forward matching topics in one or both directions. When a message is published to a bridged topic on the local broker, the bridge republishes it to the remote broker. From the remote broker’s perspective, the bridge is just another MQTT publisher.

Clients connect to whichever broker is nearest, most convenient, or explicitly configured for them. They do not know or care that other brokers exist. Messages published to a bridged topic reach both brokers’ subscribers.

What bridging does well

• Multi-site deployments. A common architecture is edge-site brokers bridged to a central regional broker. Each site’s local traffic stays local; only globally-relevant topics cross the bridge.
• Broker-vendor independence. Bridges work across broker types. A Mosquitto bridge can forward to an EMQX cluster, which can bridge to a HiveMQ instance.
• Loose coupling. Bridges can be added, removed, or reconfigured without disrupting the connected brokers themselves.
• Selective replication. You control exactly which topics are bridged, in which direction, and with what QoS.

What bridging does not do

• Provide transparent failover. If the local broker fails, its clients are cut off. Bridging replicates topic traffic between brokers; it does not automatically move clients to a surviving broker.
• Share retained messages by default. Retained messages on Broker A are not automatically retained on Broker B. Some brokers can bridge retained messages, but this needs specific configuration.
• Share sessions or QoS state. A client’s persistent session on Broker A does not exist on Broker B. If the client reconnects to Broker B, it starts a fresh session.
• Provide horizontal scale within a topic. Bridging distributes traffic across brokers by topic scope, not by client load. A single high-traffic topic still bottlenecks on whichever broker handles it.

Broker recommendations for bridging

• Mosquitto — excellent bridge support. This is the classic Mosquitto pattern for multi-site deployments. Bridging is one of Mosquitto’s strongest features.
• EMQX, HiveMQ, VerneMQ — all support bridging to other MQTT brokers. Use bridging when connecting brokers of different vendors or when clustering is not appropriate.
• Multi-site industrial deployments — Mosquitto at each edge site, bridged to a central EMQX cluster or HiveMQ instance, is one of the most common and effective architectures.

Pattern 3: Active/passive failover

Active/passive is the simplest form of redundancy: two brokers, one live and one on standby. If the active broker fails, the passive broker takes over. Clients reconnect from the failed active to the newly-promoted passive.

How active/passive works

The active broker serves all client traffic. The passive broker runs but does not serve clients; it either receives replicated state from the active continuously or takes over cold. When the active fails (health checks fail, or a supervisor process determines it is unresponsive), a control mechanism promotes the passive to active. Clients that had been connected to the old active reconnect (with retry logic) and reach the new active.

Two variants exist:

• Warm standby with replication. The passive broker continuously receives state (sessions, subscriptions, retained messages) from the active. When it takes over, clients can resume without losing significant state. Some brokers implement this natively; others require external replication tooling.
• Cold standby without replication. The passive broker is simply an installed, ready-to-run broker with no state. When it takes over, all clients reconnect from scratch with fresh sessions. Simple but disruptive.

What active/passive does well

• Simple to reason about. Two brokers, one active, one standby. The failover model is easy to explain and test.
• Compatible with any broker. Even brokers without native clustering (Mosquitto) can be run in active/passive mode with external tooling (Keepalived, HAProxy with health checks, container orchestrators).
• Predictable behavior. No consistency negotiations, no split-brain scenarios. Just two nodes, one live at a time.

What active/passive does not do

• Scale horizontally. The passive broker does nothing during normal operation; you have twice the infrastructure for one broker’s worth of throughput.
• Provide seamless failover. Client connections break during failover. Reconnection back-off is on the order of seconds to tens of seconds, and clients see visible disruption.
• Solve state replication automatically. Cold standby loses state; warm standby requires implementing (or configuring) reliable replication of sessions, retained messages, and queued QoS messages.

Broker recommendations for active/passive

• Mosquitto with external tooling — Mosquitto plus Keepalived or a similar failover mechanism is a common pattern for simple two-broker HA in industrial deployments. The state replication piece is the operational challenge.
• HiveMQ CE with orchestrator-managed failover — for teams already using Kubernetes, running HiveMQ CE in an active/passive pod configuration with persistent volumes for state is a workable pattern.
• Any broker with a shared storage backend — some brokers support external persistence layers that can be shared between an active and passive node, giving warm failover without complex replication protocols.

Pattern 4: Load-balanced brokers

Load balancing puts multiple identical brokers behind a network load balancer. Clients connect to a single load-balancer endpoint, and the balancer distributes them across broker nodes. On broker failure, the balancer removes the failed node from rotation and directs new connections to healthy nodes.

How load balancing works

The load balancer (HAProxy, an AWS NLB, an F5, Nginx, or similar) exposes a single endpoint that clients connect to. Behind it are multiple broker instances. The balancer performs health checks against each broker and directs new connections to healthy ones.

For this pattern to actually provide redundancy (not just distribution), the brokers behind the balancer must either:

• Share state via clustering. In this case, load balancing is really just the entry point for a clustered broker. The pattern effectively becomes Pattern 1.
• Be independent, and accept the loss of state on failover. Clients connecting to Broker A cannot resume their session on Broker B. In practice this means using QoS 0 or accepting that persistent sessions and retained messages are per-broker.

What load balancing does well

• Well-understood operational model. Load balancers are standard infrastructure that operations teams already run.
• Combined with clustering, provides a clean entry point. Most clustered MQTT broker deployments do exactly this: cluster on the back, load balancer in front.
• Handles connection distribution. Even without failure, spreading many client connections across multiple brokers is a real benefit at scale.

What load balancing does not do

• Fix the state problem on its own. Without clustering or state sharing, load-balanced brokers are essentially N independent brokers with a shared front door. State is not shared across them.
• Enable client-transparent failover for stateful sessions. A client that was mid-QoS-2-handshake with Broker A cannot complete that handshake with Broker B. The QoS state does not transfer.
• Handle Sparkplug B primary hosts. Sparkplug’s primary host state model is application-level; load balancing at the network layer does not integrate with it.

Broker recommendations for load balancing

• Any clustered broker + a load balancer — the standard architecture for scaled MQTT deployments. EMQX with an NLB, HiveMQ Enterprise with F5, VerneMQ with HAProxy.
• Do not use load balancing alone with non-clustered brokers — it gives you distribution without redundancy, which is worse than a single broker in some ways because failures become intermittent rather than obvious.

Pattern 5: Sparkplug primary host redundancy

For deployments using Sparkplug B, redundancy has a specific application-level pattern that is worth understanding on its own. Sparkplug’s state management model (birth/death certificates, primary host state announcements) creates opportunities for redundancy that operate at the Sparkplug layer rather than the raw MQTT layer.

How Sparkplug primary host redundancy works

In Sparkplug B, a primary host is a Sparkplug host application (typically a SCADA system) that Edge Nodes look to as their authoritative consumer. The primary host publishes STATE messages announcing its online/offline status.

For redundancy, multiple primary hosts can be configured, with Edge Nodes and devices tracking which one is currently online via their STATE messages. If the primary host goes offline, Edge Nodes can automatically switch to a secondary primary host (recognizing its STATE as authoritative) and resume operation.

This pattern is orthogonal to broker redundancy. You can combine Sparkplug primary host redundancy with any broker redundancy pattern above — brokers provide message transport availability; Sparkplug primary hosts provide application-level availability.

Additionally, Sparkplug’s rebirth mechanism (REBIRTH command messages) lets a newly-active primary host request that all Edge Nodes republish their current state, so the new primary can be brought up to date without waiting for the next data change.

What Sparkplug primary host redundancy does well

• Application-level HA for industrial IoT. Provides redundancy at the SCADA / MES layer, which is often the actual failure point for industrial deployments.
• Composable with broker redundancy. Works on top of any broker redundancy pattern; the two are independent.
• Rebirth solves the state-recovery problem. When a primary host takes over, it can pull current state from every Edge Node explicitly, avoiding the retained-message drift issues of some broker-level patterns.

What Sparkplug primary host redundancy does not do

• Replace broker redundancy. If the underlying broker fails, primary host redundancy does not help. You still need broker-level HA below the Sparkplug layer.
• Apply to non-Sparkplug deployments. This pattern is specific to Sparkplug B. Plain MQTT deployments do not have primary host state.

Broker recommendations for Sparkplug primary host redundancy

• EMQX with Sparkplug plugin — full support for Sparkplug primary host patterns, combined with EMQX’s clustering for the broker layer.
• HiveMQ Enterprise with Sparkplug extension — same story: broker HA plus Sparkplug-aware routing.
• Any MQTT broker for transport, with Sparkplug primary host logic in the SCADA layer — Ignition by Inductive Automation is the most common SCADA product implementing this pattern.

Client-side patterns for redundancy

Broker-side redundancy is only half of the story. Even the best broker HA pattern fails if clients do not know how to reconnect intelligently. The following client-side patterns are essential to real availability.

Multiple broker endpoints

Configure the client with a list of broker endpoints in priority order. On disconnect, the client tries them in order until it succeeds. This is the simplest form of client-side redundancy and works with any broker-side pattern, especially active/passive.

Every serious MQTT client library supports this. Ensure the priority order matches your deployment topology (nearest broker first, secondary as fallback).

Exponential back-off on reconnect

Clients that reconnect immediately on failure can overwhelm a recovering broker. Exponential back-off (start at 1 second, double up to a maximum) spreads the reconnection load and gives the broker time to become fully ready.

Most modern client libraries default to reasonable back-off behavior, but verify — some older or hand-rolled clients reconnect in tight loops that hurt more than they help.

Session resumption behavior

When reconnecting to a new broker, the client’s Clean Session (MQTT 3) or Clean Start (MQTT 5) flag determines whether it expects to resume or start fresh. If your brokers do not share session state (bridging, cold failover, independent load-balanced brokers), the client must be prepared for Session Present = false in the CONNACK and re-subscribe as needed.

Ensure your client logic handles both outcomes: session resumed (broker had prior state) and session fresh (broker did not, or is a different broker). Subscriptions may need to be re-issued.

QoS state during failover

For QoS 1 and QoS 2 publishes in flight during a broker failure, the client’s library either retries automatically (using its own retry buffer) or the message is lost. Understand your library’s behavior here. For applications where lost messages are unacceptable, publish with QoS 1 or 2 and ensure the client library retries pending publishes after reconnect.

For deployments where message loss during a broker failover is unacceptable, verify end-to-end that your client library retries pending QoS 1/2 publishes across a reconnect, and that your broker-side pattern preserves the necessary session state.

Application-level acknowledgement

For the highest reliability, do not rely solely on QoS acknowledgements between client and broker; add application-level acknowledgements between publisher and subscriber (via the Request/Response Pattern in MQTT 5, or via convention in MQTT 3). This adds a layer of assurance that survives any broker-level failure or message-in-flight ambiguity.

Which redundancy pattern for which situation

The right pattern depends on scale, deployment topology, and how much operational complexity you can absorb.

Small production deployment (up to ~10,000 clients), single site, cannot tolerate single-broker outage → Active/passive with Mosquitto and external failover tooling (Keepalived or Kubernetes). Simplest, cheapest, well-understood.

Multi-site industrial deployment with edge and central brokers → Bridged Mosquitto edges into central EMQX cluster (or HiveMQ Enterprise). Each edge site is autonomous; central broker aggregates. This is one of the most common and effective architectures for industrial IoT.

Cloud-scale deployment (100,000+ concurrent clients) → Clustered EMQX behind a load balancer. Accept the BSL 1.1 licensing terms. The scale and operational tooling justify the complexity.

Enterprise messaging with strict operational requirements → HiveMQ Enterprise cluster with commercial support. When downtime is contractually expensive, having a support relationship matters as much as the technical architecture.

On-premises deployment with strictly Apache 2.0 licensing → VerneMQ cluster, with careful testing of clustering reliability at your intended scale.

Industrial IoT with Sparkplug B → Broker clustering (EMQX or HiveMQ Enterprise) plus Sparkplug primary host redundancy. Both layers matter.

Development or non-critical deployment → Single Mosquitto instance. Do not over-engineer. Add redundancy only when its absence would cost more than its presence.

Common misconceptions

A few things people believe about MQTT broker redundancy that are not quite right.

“Clustering guarantees no message loss.” No. Clustering guarantees consistency of subscription state and (usually) retained messages, but in-flight QoS 1 and 2 acknowledgements during a node failure may still be ambiguous. Client-side retry is still necessary.

“Bridging is the same as clustering.” No. Bridging propagates topic messages between independent brokers; clustering shares state across nodes of a single logical broker. Bridged brokers each have their own sessions, their own retained messages, and their own consistency semantics.

“A load balancer in front of MQTT brokers gives me HA.” Only if the brokers behind the balancer also share state (via clustering). Load balancing alone distributes connections without sharing state, which is not redundancy.

“Mosquitto cannot do HA.” Mosquitto cannot do native clustering, but it can do bridging (excellent) and active/passive failover (with external tooling). Many production Mosquitto deployments have real HA using these patterns.

“I don’t need client-side reconnection logic if my broker is clustered.” Yes you do. All broker failures — even in a cluster — break the client’s connection. Client-side reconnection with back-off, endpoint fallback, and QoS retry is what turns broker HA into actual availability.

“With enough broker redundancy, MQTT can handle real-time control.” No. MQTT is not a real-time protocol. Even with the best broker HA, it should never be part of a safety interlock, closed-loop control, or any function with hard real-time deadlines. Those responsibilities belong on the PLC. MQTT is for telemetry, historian, alarms, and enterprise integration — the layer above the control system, not inside it.

“Sparkplug primary host redundancy replaces broker redundancy.” No. They operate at different layers and are complementary. You need both for full industrial IoT availability.

Testing your redundancy setup

Redundancy that has not been tested is theoretical. Before relying on any redundancy pattern in production, verify it end-to-end.

• Kill a broker mid-operation. Terminate a broker node while clients are publishing and subscribing at realistic rates. Measure how long clients take to reconnect, whether messages are lost, and whether sessions are preserved.
• Simulate a network partition. Cut the network between a broker cluster and half its clients. Verify the surviving clients continue operating and that the isolated clients reconnect cleanly when connectivity is restored.
• Test cold recovery. Bring down the whole deployment and start it fresh. Verify that retained messages are restored (or not, if your pattern does not preserve them), that sessions are handled correctly, and that Sparkplug B state (if applicable) is re-established.
• Test during load. Failover behavior at 100 clients is not the same as at 100,000. Test at your expected scale, not just at development scale.

This kind of testing is time-consuming and rarely done thoroughly. It is also the difference between an HA architecture that works and one that fails the first time it is really needed.

Frequently asked questions