Publish/Subscribe Flow Workbench

Trace how a broker turns one IoT publication into live deliveries, retained state, queued work, or no delivery.

animation
networking
mqtt
pubsub
messaging
iot-protocols
Learner-ready publish/subscribe flow workbench showing decoupling, topic-filter matching, fan-out, retained snapshots, offline queue conditions, and routing diagnostics for IoT messaging.
Messaging pattern Broker routing Intermediate with ramp

Publish/Subscribe Flow Workbench

Follow one IoT message from a publisher to a broker and then to every subscriber whose filter matches. The same trace separates live fan-out, retained latest-value state, offline-session queueing, and no-delivery cases.

Topic name factory/line1/press7/temperature
Live copies 3 subscribers
Stored state retained off
Broker result fan-out route
Publisher

A device or service sends an application message to a named topic. In MQTT, the publish topic is a concrete Topic Name.

Broker

The broker accepts the publication, checks policy, compares the topic with stored subscriptions, and creates delivery copies.

Subscriber

A subscriber registers a filter. It does not need to know which publisher will produce the matching message.

State is not one thing

A live delivery, a retained latest value, and an offline queued message are different broker behaviours.

Broker stores subscriptions before the message exists

Subscribers register filters such as factory/+/+/temperature. A publisher is not connected to each subscriber directly.

Broker route map

factory/line1/press7/temperature

The broker is ready to compare the publish Topic Name with active subscription filters.

Publish subscribe message flow A publisher sends one message to a broker. The broker may fan out to matching live subscribers, store a retained value, or queue for an offline persistent subscriber. Publisher sensor Broker match table Ops board filter match Twin sync filter match Maint tablet offline queue Retained store P

Subscription table

Routing trace

Retained store idle

Latest-value state

No retained copy is stored for this exact Topic Name.

Queue idle

Offline-session work

Offline delivery requires a matching subscription, a persistent session, eligible QoS, and broker limits that allow queueing.

Fan-out to every matching live subscription

The broker receives one publication and creates separate live deliveries for the matching filters.

Quick Reference

Pub/Sub route

  • Publisher sends to broker.
  • Broker compares topic with stored filters.
  • Each matching subscription can receive a delivery copy.

MQTT filter rules

  • + matches exactly one topic level.
  • # matches zero or more levels and must be final.
  • A published Topic Name cannot contain + or #.

State differences

  • Live delivery is for connected matching subscribers.
  • Retained state is the latest value for one exact topic.
  • Offline queues need session and QoS conditions.

Guided Practice

Find broad fan-out

Use the telemetry scenario and compare the exact filter with factory/#. The broad filter is powerful but easy to overexpose.

Separate retained from queued

Turn on retained state, then make the tablet offline. The retained copy helps a later subscriber; the queue targets an existing offline session.

Catch an invalid publish

Publish factory/+/temperature. A broker should treat this as an invalid publish Topic Name, not as a broad publish.

Technical accuracy notes

Pattern, not one protocol

Publish/subscribe is a messaging pattern. This workbench uses MQTT-style Topic Name and Topic Filter examples because they are common in IoT.

QoS is not physical success

MQTT QoS describes protocol delivery between MQTT peers. It does not prove that an actuator moved or that a field process completed.

Broker policy still matters

Authentication, authorization, retained-message limits, session expiry, queue size, and implementation policy can change the final result.

Companion Modules