Pub/Sub Architecture

IBM MQ pub/sub architecture is the blueprint for how one business event becomes many queue messages without the publisher addressing each consumer by name. At runtime the queue manager maintains a topic tree—a hierarchical index of topic strings—plus a subscription table linking patterns to destination queues. When a publisher puts a message with a topic, the pub/sub component resolves the string, finds matching subscriptions, and enqueues delivery copies. Subscribers remain queue-based consumers; the architecture deliberately preserves MQI familiarity. Clustered estates extend the same model across queue managers with proxy subscriptions and topic propagation over channels. Beginners who treat topics as “special queues” mis-size capacity and backup policies. This tutorial diagrams components, contrasts local versus cluster flows, explains administrative versus application-defined subscriptions, covers retained publications and durability at architectural level, and ties pub/sub to the object repository you already know from queues and channels.

Logical Architecture Diagram

Picture four layers. Layer 1: publisher applications using MQPUT (or JMS publish) with a topic string or topic object handle. Layer 2: the queue manager pub/sub controller consulting the topic tree and active subscriptions. Layer 3: destination queues—one per subscription path—holding copies. Layer 4: subscriber applications issuing MQGET on their DEST queues. Administration sits beside layer 2: DEFINE TOPIC shapes the tree; DEFINE SUB registers interest; DISPLAY SUB and DISPLAY TPSTATUS show runtime state on supported releases.

Publication Path Step by Step

1. Publisher connects (SVRCONN or bindings) and opens a topic for put.
2. Queue manager checks PUB authority for resolved topic string.
3. Pub/sub engine matches active subscriptions (including wildcards).
4. For each match, engine puts message to DEST with appropriate context.
5. Subscribers MQGET from DEST independently; no shared cursor on topic.

Failure before step 3 returns to publisher (not authorized). Failure at step 4 may send to DLQ or suppress copy depending on destination definition and reason code—monitor subscriber queue depth and DLQ for pub/sub routing errors.

Topic Tree and Wildcard Resolution

Strings like retail/uk/order/created form parent/child relationships. Subscriptions with retail/uk/+ match one variable level; retail/# matches all descendants. The tree stores relationships so the engine does not scan every subscription linearly against every publish in naive implementations—IBM optimizes internally, but your design still affects breadth: deep trees with thousands of wildcard subs on # increase CPU at publish time. Governance caps wildcard subscriptions in production.

Subscription Store: Durable, Non-Durable, Managed

Durable subscriptions survive subscriber disconnect—the queue manager remembers interest. Non-durable subscriptions drop when the creating application disconnects unless defined as permanent administrative subs. Managed subscriptions let the queue manager create DEST queues (common in JMS); unmanaged require you to define DEST explicitly. Architecturally, durable subs increase memory and repository footprint but support always-on analytics; non-durable suit ephemeral UI listeners.

Local Versus Cluster Pub/Sub

Local pub/sub completes entirely on one queue manager—all publishers and subscribers attach to that QM. Cluster pub/sub publishes cluster topic definitions to the repository; remote queue managers learn routes and may host proxy subscriptions so publications fan out across the cluster. Channels move messages between members; cluster sender/receiver and topic channel configuration matter. Design cluster topic names once in the full repository namespace to avoid collisions.

1
2
3
DEFINE TOPIC('RETAIL.ORDER') TOPSTR('retail/order') TOPTYPE(LOCAL)
DEFINE SUB('SUB.ANALYTICS') TOPICSTR('retail/order/#') DEST('ANALYTICS.ORDERS.Q')
* Cluster variant uses TOPTYPE(CLUS) and cluster names — see cluster topics tutorial

Retained Publications and Late Joiners

Retained publications (where configured on topic or publish options per IBM docs) let the queue manager keep the last publication for a topic so new subscribers receive a recent state snapshot—useful for configuration or inventory “current value” patterns. Architecturally this is not infinite retention like a stream log; capacity planning still uses queues and retention policies. Distinguish retain from persistent messaging—both can apply but solve different problems.

Explainer: Post Office Sorting Room

The publisher drops one letter labeled with a subject line into the sorting room (pub/sub engine). The room photocopies the letter for every person who subscribed to that subject (subscriptions) and puts copies in their pigeonholes (DEST queues). The topic is only the label on the original—not a storage bin.

Performance and Scaling Considerations

• Fan-out multiplies puts—five subscribers means five times disk I/O for persistent msgs.
• Very wide # subscriptions force large match sets at publish time.
• Deep subscriber backlogs slow perceived delivery but do not block publisher put unless queue full.
• Cluster propagation adds channel bandwidth for remote subscribers.

Monitoring Architecture

Use DISPLAY SUB(*), queue depth on DEST queues, and pub/sub status commands documented for your release. Correlate publish rate spikes with subscriber lag. Event messages can alert on failed deliveries. Include pub/sub in disaster recovery: subscriptions and topic objects live in repository—back up object definitions with standard MQSC promotion.

Explain Like I'm Five: Pub/Sub Architecture

One person shouts a headline, and the building’s mail system makes a copy for every person who asked to hear that kind of news—each copy goes to a different mailbox, not to a magic shared shelf.

Practice Exercises

Exercise 1

Draw a diagram: one publisher, topic retail/#, three subscriptions, three DEST queues.

Exercise 2

Explain what breaks if DEST queue is full while publish continues.

Exercise 3

Local vs cluster: when must publications cross a channel?

Frequently Asked Questions

Test Your Knowledge