Topics in Pub/Sub

In IBM MQ publish/subscribe, a topic is the name of a subject—not a container that hoards messages. When an order service publishes to retail/order/placed, it tells the queue manager “this message is about order placement in the retail domain.” Every subscription whose pattern matches that string receives a separate copy on its own queue. That distinction separates topics from queues: PAYMENTS.IN holds messages until someone gets them; retail/order/placed is a routing label the pub/sub engine uses to decide which queues get copies. Beginners migrating from point-to-point often search for “depth on the topic” and find none—depth appears on subscriber destination queues instead. This tutorial builds the mental model, compares topic strings versus topic objects, explains why hierarchies matter, previews wildcards at concept level, and points to administration pages for DEFINE TOPIC while preparing you for publisher and subscriber application design.

Topic as Subject, Not Mailbox

Mainframe and distributed applications already tag business meaning in COBOL copybooks and JSON eventType fields. The MQ topic string externalizes that tag at the middleware layer so routing does not depend on every consumer parsing payload first—though consumers still should validate schema. A fraud service subscribes to retail/order/#; a shipping service subscribes to retail/order/placed only; both receive overlapping events without the order service maintaining two PUT calls to two queues.

Topic Strings Versus Topic Objects

A topic string is the literal hierarchy: weather/uk/london/rain. A topic object is a friendly repository name WEATHER.UK.LONDON with attribute TOPSTR('weather/uk/london') plus TOPTYPE and cluster settings. Lab exercises often publish to strings for speed. Production uses objects so DISPLAY TOPIC shows owners, RETAIN policy, and cluster bindings; change control tracks ALTER TOPIC instead of hunting hard-coded strings in source code. Publishers can MQOPEN the object or supply the string if authorized—both resolve into the topic tree.

Hierarchical Topics and Governance

Hierarchy encodes domain boundaries: hr/benefits/enrollment versus hr/payroll/run.completed. Security grants PUB and SUB on branches—finance users cannot publish to hr/# if denied. Naming standards document allowed depth, casing, and whether country codes appear at level two. Version events in the string (v2/order/placed) or in the payload—pick one strategy per enterprise and document it so subscriptions do not multiply unnecessarily.

Fan-Out and Copy Semantics

One MQPUT to a topic with ten matching subscriptions generates ten internal puts to ten queues (simplified view). Persistent publish with persistent subscriber queues means ten durable copies on disk—capacity planning must multiply message size by subscriber count. Non-persistent publish reduces load but subscribers can miss messages if offline—durability choices belong in architecture reviews, not only in developer defaults.

Topics in Clusters

Cluster topics (TOPTYPE CLUS) advertise interest across queue managers so a publisher on QM_LON can reach a subscriber on QM_NYC without knowing the remote queue manager name in application code—cluster routing resolves it. Topics become integration contracts spanning the estate. See cluster topics administration for DEFINE specifics; conceptually the topic name is still the subject, but propagation crosses channels.

Explainer: Newspaper Section

The topic is the newspaper section name—Sports, Business, Weather. Readers (subscribers) clip articles they care about into their own folders (queues). The printing press does not store all readers’ clippings in one shared bin labeled “Sports”; it distributes copies.

When to Use Topics Versus Queues

• Use a queue when exactly one application (or competing consumers on one queue) should process each message.
• Use a topic when multiple independent systems must react to the same event.
• Use a topic when you may add subscribers later without changing the publisher.
• Stay with queues when strict ordering among all consumers on one pipeline is required—multiple subscriber queues do not share one ordering view.

Common Beginner Mistakes

1. Expecting CURDEPTH on a topic—check subscriber DEST instead.
2. Publishing without PUB authority—2035 on put.
3. Creating subscriptions but forgetting +get on DEST.
4. Using inconsistent string casing—retail/Order ≠ retail/order on case-sensitive platforms.
5. Confusing topic object name with topic string—they differ unless TOPSTR matches by design.

Explain Like I'm Five: Topics

A topic is the title on a story, not the box where books are stored. The library makes a copy for every kid who asked for books with that title.

Practice Exercises

Exercise 1

Propose five topic strings for an online store event catalog with two levels minimum depth.

Exercise 2

Given one queue consumer and three topic subscribers, sketch message counts after one publish.

Exercise 3

When would you add a TOPIC object instead of only using a string?

Frequently Asked Questions

Test Your Knowledge