Real-World Architecture Track

IBM MQ is rarely deployed as a single queue and a demo program. In production it sits between systems that were written decades apart: a CICS teller application on z/OS, a fraud scoring service in Kubernetes, a partner bank over a WAN, and a nightly batch job that posts general ledger entries. The real-world architecture track teaches you to read those estates the way integration architects and operations teams do—not as a list of object types, but as flows of business messages with delivery requirements, security boundaries, and failure modes you can monitor. This overview introduces the reference patterns used across the industry tutorials in this section, explains how hub queue managers, clusters, and pub/sub topics combine, and points you to deep dives on banking, payments, airlines, retail orders, and mainframe integration.

What You Will Learn in This Track

Each tutorial in this track answers four questions for a specific industry: what business events generate messages, which MQ objects carry them, what happens when a downstream system is slow or unavailable, and which metrics and logs prove the architecture is healthy. You will see naming examples such as PAYMENTS.REQUEST and INVENTORY.ALLOCATE—not as rigid standards, but as illustrations of how enterprises encode domain and direction in queue names so operators can triage incidents without opening application source code. You will also practice mapping message patterns (one-way, request/reply, publish/subscribe) to IBM MQ features you already studied in fundamentals: persistence, correlation IDs, dead-letter queues, channel pairs, and CHLAUTH rules at the edge.

• Banking systems — core banking, channels, and ledger handoff with strict audit.
• Payment processing — ISO-style payment messages, settlement, and idempotent consumers.
• Airline systems — reservations, availability, and irregular operations messaging.
• Retail order processing — omnichannel orders, warehouse, and inventory decoupling.
• Mainframe integration — CICS, IMS, batch, and queue sharing group placement.

Reference Architecture: Hub-and-Spoke

Many enterprises standardize on a hub queue manager (or a small number of hubs) that holds canonical queue definitions, enforces TLS and CONNAUTH, and routes traffic between spokes. A spoke might be a branch queue manager, a cloud instance, or z/OS MQ in a queue sharing group. Applications on spokes put messages to alias queues or remote queue definitions that resolve to the hub; sender-receiver channel pairs move messages when the payload must cross a machine boundary. The hub pattern trades some network hop latency for operational clarity: one team owns certificate renewal, one naming catalog, and one set of depth monitors for critical queues.

Message Patterns Across Industries

Different industries stress different MQ capabilities, but the same four patterns appear repeatedly. Fire-and-forget one-way puts suit event notifications—flight gate changed, order shipped—where no immediate reply is required. Request/reply with ReplyToQ and CorrelId suits interactive work—balance inquiry, seat hold—where the caller waits or polls a reply queue. Publish/subscribe with topics suits fan-out—fare sale announced to pricing, web, and loyalty systems. Batch handoff uses persistent queues drained overnight while online systems enqueue during the day. Understanding which pattern applies prevents misconfigured queues: a request/reply flow needs a reply queue and correlation discipline; a pub/sub flow needs topic authority and durable subscriptions where late joiners must receive retained data.

Cross-Cutting Operational Concerns

Real architectures fail in predictable ways: channels enter retry when a firewall changes, depth grows when a consumer deployment fails, poison messages loop until they reach a dead-letter queue. The track assumes you will use DISPLAY QSTATUS, DISPLAY CHSTATUS, AMQERR logs, and message IDs to trace a single payment or order through the bus. Security is never optional at the hub: CHLAUTH on inbound channels, MCAUSER with least privilege, and setmqaut grants that follow group-based roles rather than personal user IDs embedded in application servers.

1
2
3
4
5
6
* Example: operations health check on a hub payments queue
DISPLAY QSTATUS('PAYMENTS.REQUEST') CURDEPTH IPPROCS OPPROCS
DISPLAY CHSTATUS('BRANCH.TO.HUB') WHERE(CHSTATUS NE RUNNING)
* CURDEPTH — messages waiting; compare to BOTHRESH and MAXDEPTH
* IPPROCS — applications with queue open for input (consumers)
* OPPROCS — applications with queue open for output (producers)

Explainer: City Road Network

Think of IBM MQ as a road network between buildings that cannot share one database. Highways (channels) connect cities (queue managers). Parking lots (queues) hold trucks (messages) until a warehouse (consumer) is ready. A hub city has the main sorting facility; spoke towns send everything through it so each town does not pave roads to every other town. Traffic lights (flow control, MAXDEPTH) prevent one parking lot from filling the entire city.

How the Tutorials Connect

1. Banking systems — account lifecycle, channels to core, audit and RACF on z/OS.
2. Payment processing — ISO 20022 style flows, settlement windows, idempotency keys.
3. Airline systems — PNR-related messaging, inventory, and irregular ops broadcast.
4. Retail order processing — cart, allocation, ship confirm, returns.
5. Mainframe integration — CICS bridge, syncpoint with Db2, QSG considerations.

Design Checklist Before You Draw Diagrams

• Identify producers and consumers by application name, not only by server hostname.
• Mark persistence requirement per message type (regulatory vs informational).
• Decide hub versus peer channels for each trust zone (DMZ, cloud VPC, mainframe).
• Define poison message and DLQ handling with backout threshold on each work queue.
• Plan HA for queue managers that hold irrecoverable backlog (payments hub).
• Document correlation and reply queue naming for every request/reply pair.

Explain Like I'm Five: Real-World MQ

Real-world MQ is like the mail system for a whole company. Different departments send letters (messages) to the mail room (queue manager). The mail room holds letters in boxes (queues) until the right department picks them up. Some letters must never be lost (persistent), and some need an answer sent back to the same person who asked (request/reply). This track shows what those letters are in banks, shops, and airplanes.

Practice Exercises

Exercise 1

Draw a hub with three spokes (branch, cloud, z/OS). Label one sender-receiver pair per spoke and list which queues exist only on the hub.

Exercise 2

For a fictional retail order, classify each step as one-way, request/reply, or pub/sub: order placed, fraud check, inventory hold, ship confirm.

Exercise 3

Write five monitoring alerts you would attach to a payments hub (queue depth, channel status, disk, etc.).

Frequently Asked Questions

Test Your Knowledge