Topic Clustering Best Practices

Topic clustering best practices distill what operations teams learn after the first cluster-wide pub/sub outage: one CLUS object per business domain, scope attributes chosen on purpose, ACLs identical on every member, subscriptions consolidated instead of sprouted, and monitoring that treats cluster channel bytes as part of event throughput. IBM MQ does not forgive accidental prod/# SUBSCOPE(ALL) on twelve queue managers—routing tables grow, security exposure widens, and the first Black Friday publish saturates CLUSSDR links. This tutorial is a design guide for beginners and architects: repository hygiene, hierarchy alignment, security matrix, capacity formulas, testing checklist, upgrade and migration notes, anti-patterns from real incidents, and handoff documents for development teams publishing into a cluster.

Topic Object Layout

Standard pattern: CLUS administrative parent at prod/domain/entity with TOPSTR matching three segments; LOCAL children for each event leaf; ALIAS topics only for migration. Example: PROD.RETAIL.CLUS → prod/retail (CLUS, CLUSTER CORP, PUBSCOPE ALL, SUBSCOPE ALL); PROD.RETAIL.ORDER.CREATED → prod/retail/order/created (LOCAL, ADMINTOPIC parent). Publishers use leaf strings; repository carries one cluster definition per branch.

shell
1
2
3
4
5
6
7
DEFINE TOPIC('PROD.RETAIL.CLUS') TOPSTR('prod/retail') TOPTYPE(CLUS) + CLUSTER('CORP') PUBSCOPE(ALL) SUBSCOPE(ALL) DESCR('Retail cluster root') DEFINE TOPIC('PROD.RETAIL.ORDER.CREATED') + TOPSTR('prod/retail/order/created') TOPTYPE(LOCAL) + ADMINTOPIC('PROD.RETAIL.CLUS') DEFINE SUB('RETAIL.ANALYTICS') TOPICSTR('prod/retail/#') + DESTQL('RETAIL.ANALYTICS.Q') SUBSCOPE(ALL) DURSUB(YES) DESTTYPE(UNMANAGED)
Best practice checklist
PracticeBenefitAnti-pattern
CLUS at domain root onlyClean repositoryCLUS on every leaf
Document PUBSCOPE/SUBSCOPEPredictable fan-outDefault ASPARENT without review
Replicate topic ACLsSymmetric securityACL only on primary QM
Consolidate ALL subsLower routing loadPer-app ALL on prod/#
Monitor CLUS channelsEarly overload detectOnly monitor local CPU
Lab three-QM testProve routing pre-prodFirst test in production

Scope Pairing Guide

Publishing-only site: PUB granted, SUB denied on sensitive branches, SUBSCOPE QMGR on any required local monitoring subs. Central analytics hub: SUBSCOPE ALL on narrow patterns, no PUB on production event branches. DR site: replicate CLUS definitions and ACLs before failover drill; verify subscriptions reload on cold start. ASPARENT only when parent SUBSCOPE and PUBSCOPE are explicitly approved in architecture board minutes—not because it is the default in samples.

Security and Compliance

  • Export topic ACLs from every cluster member monthly; diff them.
  • Separate test cluster from production cluster name—never share CORP name.
  • TLS on all cluster channels; rotate certs with cluster channel recycle plan.
  • Restrict who may ALTER CLUS topic objects—routing blast radius.
  • Data residency: document which QMs may host SUBSCOPE ALL for regulated topics.

Capacity Planning

Estimate: publish rate × matching subscription count × average message size × remote factor = cluster channel load. Wildcard subs on prod/retail/# multiply matches. Add 30 percent headroom for retain and DLQ copies. Size DEST MAXDEPTH on each subscriber QM for offline duration. Full repository queue managers need CPU for repository updates—do not starve REPOS role systems.

Testing Checklist Before Go-Live

  1. Publish from each expected publisher QM; verify DEST on each subscriber QM.
  2. Stop one CLUSSDR; confirm behavior matches RTO/RPO design.
  3. Negative test: principal without PUB cannot publish.
  4. Failover repository QM; confirm topic defs visible after recovery.
  5. Load test at 2× expected peak for thirty minutes; watch channel bytes.

Migration From Single QM to Cluster

Introduce CLUS parent at existing domain prefix without changing publish strings. Add SUBSCOPE ALL only where cross-QM delivery required. Roll ACL scripts to new members before switching publishers. Run parallel consume from old local subs and new cluster subs during cutover window; compare message counts. Remove QMGR-scoped subs after validation.

Anti-Patterns to Avoid

  • Flat topic codes without hierarchy—cluster cannot help organization.
  • Duplicate CLUS parents for same TOPSTR on different CLUSTER names.
  • Developers granted PUB and SUB on prod/# for convenience.
  • No DISPLAY SUB audit after each microservice release.
  • Assuming publish success implies all sites received—monitor each DEST.

Explainer: Highway System Design

Cluster topic design is planning highways between cities (queue managers): few main interchanges (CLUS parents), local roads for neighborhoods (LOCAL leaves), toll rules (ACLs) identical at every city gate, and traffic counters on interstates (channel monitoring)—not paving a separate highway for every house.

Explain Like I'm Five: Topic Clustering Best Practices

When many schools share announcements, you use one main rule book, the same safety rules at every school, and only send copies to schools that signed up—not shout every story to every school in the world.

Practice Exercises

Exercise 1

Design CLUS parent plus two LOCAL leaves for logistics domain.

Exercise 2

Write pre-go-live test checklist with five steps.

Exercise 3

Calculate channel load: 500 msg/s × 8 subs × 4 KB.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. CLUS topic should usually be at:

  • Domain branch root
  • Every leaf event
  • DLQ only
  • Listener

2. Leaf events typically use:

  • TOPTYPE LOCAL
  • TOPTYPE CLUS only
  • CHLTYPE SDR
  • XMITQ

3. ACLs on cluster need:

  • Same grants on each QM
  • Only one QM
  • No OAM
  • FTP only

4. SUBSCOPE ALL on prod/# for many apps:

  • Avoid—capacity and security risk
  • Required always
  • Disables TLS
  • Deletes topics
Published
Read time18 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation