Publish/Subscribe Messaging

Publish/subscribe (pub/sub) is how IBM MQ broadcasts business events to many interested applications without the publisher knowing every receiver in advance. A producer publishes to a topic string—such as retail/order/placed—and the queue manager routes matching messages to subscriber queues. Each subscriber application gets from its own queue, preserving the familiar MQI programming model while enabling fan-out. This page explains topics versus queues, topic trees and wildcards, subscriptions and subscriber queues, durable versus non-durable subscribers, retained publications for late joiners, capacity implications, and MQSC you can run in a lab. If you already understand point-to-point queues, pub/sub adds a routing layer on top of the same queue manager reliability.

Publisher, Topic, and Subscriber Roles

The publisher puts a message with a topic string (or resolves a topic object that carries the string). The queue manager pub/sub component compares active subscriptions. For each match, it enqueues a copy on the subscription destination queue. The subscriber program does not subscribe at runtime in the MQI sense of blocking on a topic—it uses a subscription object created by administration or the application, then gets from the destination queue.

This separation lets operations add a new subscriber—analytics, audit, email—without redeploying the publisher, provided the topic contract and payload schema are stable. Governance uses topic catalogs: who may publish to production finance/* topics, which schemas are versioned, and how test topics are isolated from production trees.

Topic Strings and Topic Objects

A topic string is a hierarchical name, often slash-separated: country/region/store/event. Topic objects (DEFINE TOPIC) optionally anchor strings in the object catalog with attributes such as description, cluster routing, and retention. Publishers may put using the string directly or open a topic object. Subscriptions reference topic strings or topic objects plus optional wildcard characters.

Subscriptions and Subscriber Queues

DEFINE SUB creates a subscription with a topic string (or reference), destination queue, and optional user identity. DEST names the queue that receives publications—often a dedicated queue per subscriber application. When the subscription is active, each matching publish creates one put to that queue. Shared subscriptions (where supported in your release) allow multiple consumer instances to share one subscription load; exact behavior depends on IBM MQ version and platform—consult your documentation for SHARED and destination options.

Durable subscriptions survive subscriber application restarts: unprocessed messages remain on the destination queue. Non-durable patterns suit ephemeral clients. JMS durable subscribers map to this concept with a client ID and subscription name. Beginners should display subscriptions (DISPLAY SUB) and monitor destination depth alongside publisher rates.

Pub/Sub vs Point-to-Point

Use queues when one logical handler must process each message—payment instruction, single inventory update. Use topics when multiple handlers may process the same publication independently—order placed triggers warehouse, billing, and loyalty. Accidentally publishing a command-like message to a broad wildcard topic can cause duplicate side effects unless every subscriber is idempotent. Accidentally using a queue when many systems need the same event forces sequential fan-out or multiple puts from the publisher, recoupling the architecture.

Persistence, Ordering, and Fan-Out Cost

Persistent publications are logged and stored per subscriber copy. Ten persistent subscribers mean ten durable copies on disk or CF structures. High-volume topics need capacity planning for subscriber count, message size, and retention. Ordering is generally preserved per subscriber queue, not globally across subscribers. One subscriber may be behind while another is current—normal in event-driven systems.

Retained publications (when enabled on a topic) keep the latest message for new subscriptions—useful for configuration or latest price, not a full history. See the event-driven systems tutorial for business context; enable retention only where a single latest value is correct.

Cluster and Remote Pub/Sub

In multi-queue-manager estates, publications can route between queue managers via clustered topics and pub/sub channels. A publisher on a spoke can reach subscribers on the hub or peer systems. Channel and authority configuration must allow publish and subscribe across managers. Mainframe hubs often centralize topic trees while distributed systems publish into the same logical namespace through cluster aliases.

Tutorial: Topic, Subscription, and Test Publish

Run on a lab queue manager. After definitions, publish with amqspub or an application using topic string retail/demo/hello; verify depth on the subscriber queue with DISPLAY QLOCAL.

1
2
3
4
5
6
7
8
9
DEFINE TOPIC('DEMO.HELLO.TOPIC') TOPICSTR('retail/demo/hello') +
  DESCR('Demo pub/sub topic')
DEFINE QLOCAL('DEMO.SUBSCRIBER.Q') REPLACE MAXDEPTH(50000)
DEFINE SUB('DEMO.HELLO.SUB') TOPICSTR('retail/demo/hello') +
  DEST('DEMO.SUBSCRIBER.Q') +
  DESCR('Demo subscriber')
DISPLAY SUB('DEMO.HELLO.SUB') ALL
* Publish: amqspub retail/demo/hello 
* Consume: amqsget DEMO.SUBSCRIBER.Q 

Explain Like I'm Five: Publish/Subscribe

A topic is like announcing on the school intercom: "Today is pizza day." Everyone who signed up to listen for lunch news hears it—the kitchen, teachers, and your friend who loves pizza. Each listener still gets the message in their own notebook (subscriber queue). A queue is like handing one note to one person in line. Pub/sub is the intercom; point-to-point is the single note.

Practice Exercises

Exercise 1: Wildcard Design

Write three topic strings and one subscription with + or # that matches two of them but not the third.

Exercise 2: Fan-Out Math

One persistent publish, five subscribers, average message 4 KB. Estimate durable storage if all queues are empty before publish.

Exercise 3: Queue or Topic?

Choose queue or topic: fraud alert to one engine; product price change to web, mobile, and cache.

Frequently Asked Questions

Test Your Knowledge