Point-to-point messaging is easy to picture: one MQPUT lands on one queue, one consumer MQGETs it. Publish/subscribe adds a fan-out layer inside the queue manager—a publisher names a topic such as price/eq/IBM, and the pub/sub engine must discover every subscription that cares about that event, then deliver a copy to each subscriber destination without the publisher knowing subscriber identities. That matching engine is invisible in MQ Explorer until throughput spikes or subscriptions go missing after restart. Beginners configure TOPIC objects and SUB subscriptions in MQSC; internals explain why a typo in topic string hierarchy blocks all downstream subscribers, why durable subscriptions survive queue manager bounce, and why cluster pub/sub multiplies traffic across queue managers. This tutorial covers topic tree resolution, subscription tables, publish path versus subscribe path, retained publications, authority checks, cluster propagation at overview level, and performance pitfalls for estates moving from queues-only to event-style interfaces.
Topics are organized hierarchically like folders: finance/payments/approved. TOPIC objects define branches and attributes—whether the branch is cluster-visible, if publish is allowed, if subscriptions must be administrative. When a publisher supplies a topic string, the engine walks the tree, applying defaults from the nearest defined TOPIC ancestors. A publish to finance/payments/approved inherits constraints from finance and finance/payments if those nodes exist. Wildcard subscriptions use characters such as # for multi-level and + for single-level segment matching per IBM rules—broad patterns increase match work on every publish.
| Subscription pattern | Relative match cost | Guidance |
|---|---|---|
| Exact topic string | Low | Prefer for high-rate feeds |
| Single-level + wildcard | Medium | Use for one variable segment |
| Multi-level # at root | High | Avoid on hot topics |
| Thousands of distinct subs | High cumulative | Partition across topics |
Non-persistent publish to non-durable subscriber queues is the fast path—minimal log work for undelivered copies if subscribers are down messages may be lost. Persistent publish or durable subscriptions engage logging and disk like normal queue puts. Mixed estates often accidentally mark publishers persistent while subscribers are non-durable—surprising disk use without delivery guarantees subscribers expect.
SUB and administrative subscriptions store topic string, destination, subid, user, and durability. Durable subscriptions survive subscriber application disconnect; the engine holds state so the next publish still delivers. Non-durable subscriptions exist only while the subscribing application maintains registration—useful for ephemeral UI clients, dangerous for batch jobs that exit. DISPLAY SUB and MQSC DELETE SUB are operational levers; orphaned durable subscriptions after application decommission are a common clutter source slowing matching.
1234DEFINE TOPIC('FINANCE.PAYMENTS') TOPICSTR('finance/payments') DEFINE SUB('PAYMENTS.BACKOFFICE') TOPICSTR('finance/payments/approved') TOPICOBJ('FINANCE.PAYMENTS') DESTQL('BO.PAYMENTS.IN') DURSUB(YES)
Retained messages (where supported and enabled on topic) let late-joining subscribers receive the last published value without a live publisher waiting—similar in spirit to retained MQTT messages. The engine stores the retained payload in controlled structures; changing retained content too frequently can create hot spots. Security: retained payloads may hold sensitive data readable by any new subscriber matching the topic—tighten OAM on subscriber queues and topic publish authority.
In a cluster, publications may propagate to other queue managers so remote subscribers receive events. Cluster topics and routing agents interact with channel agents and repository data—symptoms of cluster pub/sub issues include subscribers on QM2 never seeing publishes from QM1 while local subscribers on QM1 do. Fix repository sync and cluster channels before blaming the pub/sub engine alone. Dedicated cluster topic tutorials cover administrative objects; here the takeaway is fan-out may cross QM boundaries.
Publish requires authority on the topic or parent; subscribe requires authority to attach and put to destination queue. The engine enforces OAM checks during publish and subscribe registration. A publish that succeeds locally but fails remotely in cluster may be cluster auth or channel issue, not engine bug. Use DISPLAY AUTHREC and consolidated naming standards for service accounts.
High fan-out means many internal puts per single publish—CPU, log, and lock contention rise together. Splitting topics by business domain reduces wildcard scans. Coalesce fine-grained events at the publisher when subscribers need batches anyway. Read buffer management and locking internals for how memory pools and internal locks amplify pub/sub storms during month-end jobs.
Publishing is the principal speaking on the PA: "Bus 4 is leaving." Subscriptions are classrooms that turned on the speaker for bus announcements. The pub/sub engine is the switchboard that connects the microphone only to rooms that asked for bus news—not to rooms listening for lunch menus.
The pub/sub engine is the helper who hears one person shout news and then whispers the same news to every friend who signed up to hear that kind of news.
Create exact and wildcard subscriptions; publish once; count destination depths.
Compare durable versus non-durable behavior after subscriber application exit.
Document fan-out ratio for your busiest topic (publishes per second × subscribers).
1. Pub/sub engine matches:
2. One publish can create:
3. Topic string wildcards:
4. Durable subscription survives: