Integration & Gateways · Study deck

Pub/Sub and Topic Routing

A greenhouse probe publishes humidity without knowing which dashboard, alarm service, or archive will use it.

Gateway Gus is your guide for this deck.

commbridgepubsub

After studying this chapter

Learning objectives

You will be able to:

design topic names as a stable contract rather than an implementation detail
explain why wildcard subscription matching is not the same as authorization
distinguish per-hop QoS delivery guarantees from end-to-end exactly-once delivery
diagnose retained-message replay traps and dead-letter routing failures

Major section

Publishers Speak to Topics, Not People

A broker is the service that matches a named message route to interested readers.

A gateway is a device or service that joins different networks or data forms.
The sensor may know neither the dashboard nor the gateway, so the route and access rules must carry the promise.
Practitioner designs names, filters, and records.

Pub/sub routing is a broker contract: publishers send once, then the broker matches subscriptions and fans out bounded copies to approved consumers.

Major section

Publishers Speak to Topics, Not People (continued)

A match proves routing, not permission or useful action.

The shared route can inform many users, but it should not become the only path to an immediate safety step.
This opening does not choose a topic tree or delivery level.
Under the Hood examines match rules, saved state, queue behavior, replay, access limits, and bridge failures.
The example topic gives the event a stable route while keeping the sender unaware of who is listening.

Major section

Read a Topic as a Public Contract

One publish delivered to three subscribers is one observed sensor topic message and three deliveries, not three humidity measurements.

The publisher sends a routing record to a named topic rather than to a particular application.
A display subscribes to farm/+/humidity, while an archive subscribes to farm/#.
The multi-level # includes all descendant farm topics.

Major section

Read a Topic as a Public Contract (continued)

This separation lets one consumer stop without changing the probe, but it also makes the topic tree an interface that deserves version control.

A sensor publishes {"value":68.4,"unit":"%","observed_at":"10:05:20"}.
The single-level + selects humidity from any one greenhouse name at that position.
Topic names should carry stable routing facts, not values that change every reading.

Major section

Read a Topic as a Public Contract (continued)

A maintenance command must use a separate, access-controlled branch rather than hiding state-changing writes among telemetry.

Putting 68.4 in a topic would create unbounded routes and make numeric filtering look like address selection.
A retained value can give a new dashboard the latest known state, but its observation time must reveal whether it is stale.
Those details make routing behavior reviewable after the subscriber list grows.

Major section

Read a Topic as a Public Contract (continued)

Redelivery can protect against loss, but a duplicate-safe topic consumer still needs a topic message identifier.

A useful pub/sub release routing record includes topic examples, wildcard boundaries, payload schema, retained policy, delivery level, authorization rules, and evidence from an allowed and denied route.
This distinction keeps volume dashboards and duplicate investigations honest.
An indefinite dual publish can double actions and conceal abandoned clients.

Major section

Checkpoint: Summary

In pub/sub, publishers send to named topics and the broker delivers copies to matching subscribers; neither side addresses the other, which is the model's strength and its contract risk.

A topic name is a routing contract: once consumers depend on it, the level order and meaning cannot change without breaking dashboards, automations, and bridges.
Wildcards + (one level) and # (trailing levels, last segment) are about matching; the real review question is whether the subscriber is authorized for everything the filter matches.
Fan-out turns one publication into many deliveries, so estimate it per topic family and bound the behavior when a consumer is slow or disconnected.

Deck summary

Key takeaways

A broker is the service that matches a named message route to interested readers.

A match proves routing, not permission or useful action.
One publish delivered to three subscribers is one observed sensor topic message and three deliveries, not three humidity measurements.
This separation lets one consumer stop without changing the probe, but it also makes the topic tree an interface that deserves version control.
A maintenance command must use a separate, access-controlled branch rather than hiding state-changing writes among telemetry.

Retrieval practice

Recall check 1 of 4

Gateway Gus says: answer from memory, then check your reasoning.

Q1In publish-subscribe routing, how does a publisher reach a consumer?

ABy opening a direct request-response session with each consumer and waiting for an acknowledgement

BBy requiring each consumer to poll the publisher device on a fixed collection schedule

CIt publishes to a topic; the broker matches subscriber filters and forwards copies

DBy having the broker broadcast every publication to every connected client

Show answer

Answer: C Pub/sub decouples producers from consumers through topics and the broker's matching.

Retrieval practice

Recall check 2 of 4

Gateway Gus says: answer from memory, then check your reasoning.

Q2A dashboard subscribes to 'plant-a/#' because it was easy during testing, but it only displays meter power values from one line. What is the best review action?

AKeep the broad filter because one subscription reduces the dashboard's configuration work

BSwitch the subscription to QoS 2 so the broad filter has stronger delivery semantics

CUse the narrowest authorized filter that covers only the required meter-power topics

DMove sensitive identifiers into the topic so the dashboard can filter them locally

Show answer

Answer: C A broad wildcard increases data exposure and fan-out; the filter should match only the required topic family within the authorization boundary.

Retrieval practice

Recall check 3 of 4

Gateway Gus says: answer from memory, then check your reasoning.

Q3A bridge has a retained command and a rejected message. What two failure paths need explicit policy?

AGive every subscriber the command wildcard, with no stale-command expiry.

BTreat retained commands as fresh and silently drop rejected messages.

CBlock stale command replay and send rejected work to a visible dead-letter queue.

DRaise QoS and keep no failure counters for retained or rejected work.

Show answer

Answer: C A reconnect may replay an old action, while invalid work must remain reviewable.

Retrieval practice

Recall check 4 of 4

Gateway Gus says: answer from memory, then check your reasoning.

Q4A team sets the highest QoS so that each command runs exactly once across the whole pipeline. Why is QoS alone not sufficient?

AThe broker's duplicate suppression covers command execution

BQoS covers transport, not exactly-once command execution.

CCommands need a retained state to complete delivery

DRaising QoS disables retained messages entirely.

Show answer

Answer: B End-to-end exactly-once is an application property built on idempotency and stable identifiers, not a guarantee a QoS level can provide on its own.

Print reference

Answers

Answer key.

C · Pub/sub decouples producers from consumers through topics and the broker's matching.
C · A broad wildcard increases data exposure and fan-out; the filter should match only the required topic family within the authorization boundary.
C · A reconnect may replay an old action, while invalid work must remain reviewable.
B · End-to-end exactly-once is an application property built on idempotency and stable identifiers, not a guarantee a QoS level can provide on its own.