Stand with Ukraine flag

MQTT GUIDE

3 min read

MQTT Shared Subscriptions Explained

Quick answer

A shared subscription lets a group of MQTT clients share one subscription so each message is delivered to only one member of the group, instead of to all of them. That turns MQTT’s broadcast model into a load-balanced work queue for scaling consumers horizontally.

The problem shared subscriptions solve

A normal MQTT subscription is a broadcast: if ten clients subscribe to the same topic, every one of them receives every message. That's perfect for fan-out, but it can't spread load. If a single high-traffic topic produces more messages than one consumer can handle, a normal subscription gives you no way to share the work.

How shared subscriptions work

A shared subscription puts several clients into one consumer group. The broker then delivers each message to only one member of the group, turning the topic into a load-balanced work queue. Clients join a group by subscribing to a special topic form:

$share/<group-name>/<topic-filter>

For example, three worker services that all subscribe to $share/workers/sensors/+/data form the workers group. Each reading published under sensors/+/data goes to just one of the three workers, so adding a fourth worker instantly increases throughput.

Messages on sensors/+/data M1 M2 M3 M4 BROKER $share/workers/sensors/+/data Worker 1 Worker 2 Worker 3 M1 · M4 M2 M3 Each message goes to just one group member — commonly round-robin
A shared subscription spreads each message across the group — one message, one worker

MQTT 5.0 vs 3.1.1

Shared subscriptions are a standard feature of MQTT 5.0. Some brokers also offered them as a non-standard extension under MQTT 3.1.1 using the same $share convention, so behavior can vary by broker on 3.1.1.

Common use cases and pitfalls

Scaling consumers — worker pools that process high-volume ingestion.
High availability — if one consumer drops, others in the group keep working.
Watch ordering — messages are spread across consumers, so don't rely on strict global order.
Mind QoS — combine with the right QoS level for your delivery guarantees.

Shared subscriptions in TBMQ

TBMQ supports shared subscriptions and distributes each message across the group in round-robin order. For high-throughput APPLICATION clients it backs the shared subscription with a dedicated Kafka topic, so you can add consumer instances to absorb load and scale throughput horizontally. See the shared subscriptions guide for setup and the application-vs-device client details.

Frequently asked questions

What is the $share prefix?

The $share/<group>/<topic> prefix marks a subscription as shared. Every client that subscribes with the same group name and topic joins one consumer group, and the broker delivers each matching message to only one member of that group.

Do all brokers support shared subscriptions?

Shared subscriptions are standard in MQTT 5.0, and some brokers also supported them as an extension in MQTT 3.1.1. Support varies, so check your broker. TBMQ supports shared subscriptions for any MQTT version it serves — 3.1, 3.1.1, and 5.0.

How is a message distributed within a group?

The broker picks one member of the shared group per message (commonly round-robin). Different brokers may use slightly different selection strategies.

Do shared subscriptions guarantee ordering?

Because messages are spread across multiple consumers, strict global ordering is not guaranteed. Design consumers to tolerate out-of-order or parallel processing.

Run it yourself

TBMQ is a free, open-source MQTT broker built to scale. Spin it up in minutes or try the live demo — no install required.