Ordinary MQTT delivery is a fan-out: every subscriber to a topic receives every matching message. That is exactly what you want for dashboards and displays, but it is the wrong model when a single service can no longer keep up with a high-volume telemetry stream and you need several copies of that service to share the load. A shared subscription solves this. Multiple consumers join a named group, and the broker hands each message to only one member of the group rather than to all of them. This guide explains the $share syntax, how the broker distributes messages, and why shared subscriptions matter when scaling the ingestion tier of a cloud SCADA system.
MQTT Shared Subscription in one line: An MQTT shared subscription lets several clients form a named group that jointly subscribes to a topic, and the broker delivers each matching message to only one member of the group instead of to all of them. It turns MQTT's default fan-out into load balancing, so a demanding telemetry stream can be spread across multiple consuming servers that each process a share of the messages.
By default MQTT is a publish-subscribe system in the purest sense, meaning every client subscribed to a matching topic gets its own copy of every message. Two operator screens watching the same well both see every reading, and that is the behaviour that makes MQTT so convenient for monitoring. The problem appears on the processing side. If one server subscribes to a firehose of telemetry and cannot handle the rate, adding a second server the ordinary way does not help, because the second server simply receives the same messages as the first and both fall behind together.
A shared subscription changes the delivery rule for a defined set of consumers. Instead of every subscriber getting every message, the members of a shared group collectively receive the stream exactly once, with the broker choosing one group member to hand each individual message to. Adding another consumer to the group now genuinely reduces the load on the others, because the broker spreads the messages across all available members. This is the same idea as a consumer group in a message queue, brought into MQTT.
The subscription is identified by a shared name so the broker knows which clients belong together. The rest of MQTT is unchanged: publishers do not need to know that a shared subscription exists, they publish to the topic exactly as before, and the broker takes care of choosing one recipient per message among the group. A system can even mix models, with a shared group of workers load-balancing the ingestion while separate ordinary subscribers still receive the full fan-out for live display.
Shared subscriptions are requested through a special topic-filter prefix. A client subscribes to a filter of the form $share followed by a group name and then the actual topic filter, so that a group called ingest subscribing to a site telemetry topic uses a filter that begins $share/ingest/ and then continues with the normal topic pattern including any wildcards. Every client that subscribes with the same group name and the same topic filter joins the same load-balancing group, and the broker treats them as interchangeable recipients.
The group name is arbitrary and chosen by the system designer, and different group names create independent groups. That independence is useful: a stream can feed both an ingest group that writes to the historian and a separate alarms group that evaluates conditions, and each group receives its own complete copy of the stream while balancing internally across its own members. Within a group, the broker distributes messages by some scheme of its choosing, commonly a round-robin or least-loaded approach, and the exact policy varies between broker implementations.
There are practical details worth respecting. Message ordering across the group is not the same as ordering on a single connection, because consecutive messages may go to different members, so consumers should not assume they see a strictly ordered slice of the stream. Quality-of-service and acknowledgement still apply per delivery, so a message handed to one member that fails to acknowledge can be redelivered, and a well-designed consumer keeps its per-message processing idempotent so a redelivery does no harm.
In a cloud SCADA platform the ingestion tier is where scale pressure shows up first. Telemetry from a large fleet of wells, tanks, and compressors converges on the broker, and the services that decode payloads, validate them, and write them to the historian must keep pace with the combined rate of every site. A single ingestion process is a bottleneck and a single point of failure. A shared subscription lets the platform run a pool of identical ingestion workers that jointly consume the stream, so throughput scales by adding workers rather than by making one worker ever faster.
This model also improves resilience during operation. If one worker in the group crashes or is taken down for a deployment, the broker simply stops sending it messages and continues distributing across the survivors, and the stream keeps flowing without a gap. When the worker returns, or a new one is started to handle a growth in field devices, it joins the group and immediately begins taking a share. The operations team can grow and shrink the ingestion pool to match the number of sites reporting without changing anything at the edge or reconfiguring publishers.
For a platform such as Merobix ingesting from many remote sites, shared subscriptions are a natural fit for the parts of the pipeline that are pure work distribution, such as parsing and storing readings, while ordinary subscriptions remain the right choice for anything that needs every message, such as a live map or an alarm annunciator. The distinction is between work that should be done once per message and information that should reach every interested viewer. Shared subscriptions give the former without disturbing the latter.
A normal MQTT subscription delivers every matching message to every subscriber, which is a fan-out. A shared subscription groups several clients under one shared name and delivers each message to only one member of that group, which is load balancing. You use a normal subscription when everyone needs the data and a shared subscription when you want to spread the processing across several servers.
When a member of a shared group disconnects, the broker stops selecting it and distributes messages among the remaining members, so the stream continues without that consumer. Any message that was handed to it but not acknowledged may be redelivered to another member depending on the quality-of-service level. This is why load-sharing consumers are usually written to process messages idempotently, so an occasional redelivery causes no harm.
No. Publishers are completely unaware of shared subscriptions. They publish to the ordinary topic exactly as they always would, and the broker decides whether to fan a message out to normal subscribers, balance it across a shared group, or both. All the shared-subscription logic lives on the subscribing side through the $share topic-filter prefix.
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.