Event-Driven Systems

Event-driven architecture treats business occurrences—order placed, payment cleared, policy renewed—as first-class messages that many systems may observe and react to independently. IBM MQ supports this style through publish/subscribe topics, subscriptions, and subscriber queues, while still offering point-to-point queues for command-like workloads. This page introduces events versus commands, pub/sub with topics, common event-driven patterns, using MQ as an enterprise event backbone between mainframe and distributed applications, and a beginner-friendly introduction to retained publications for late-joining subscribers.

Events vs Commands

A command message tells a consumer to perform an action: "reserve inventory for order 4471," "post this journal entry," "run credit check for customer X." The sender usually expects a specific application (or pool of workers on one queue) to handle it. Point-to-point queues fit commands well: each message is typically consumed once, and queue name often implies the responsible service.

An event message announces that something already happened: "Order 4471 was placed," "Payment 992 cleared," "Customer address changed." The publisher does not need a list of every downstream system. Subscribers choose whether to care—fulfillment listens to order events, marketing might listen to address changes, audit listens to everything in a scope. Events favor loose coupling and extensibility: new subscribers can be added without changing the publisher if the topic contract is stable.

In practice, the same MQ infrastructure carries both. Naming and schema discipline prevent confusion: command queues named for the service (INVENTORY.CMD) versus event topics named for the business fact (retail/order/placed). Mixing command semantics on a broadcast topic can cause duplicate processing unless every subscriber is idempotent. Beginners should ask: "Should more than one system react the same way to this message?" If yes, lean event and topic; if no, lean command and queue.

Publish/Subscribe with Topics

IBM MQ implements pub/sub with topics, publications, and subscriptions. A publisher puts to a topic string (or resolves a topic object). The queue manager matches active subscriptions and delivers copies to subscriber queues—one queue per subscription (or shared subscription patterns in advanced setups). Subscribers issue gets on their queues like any other MQI consumer; they do not read the topic directly.

Topics are often organized in a hierarchy, for example finance/payment/completed. Subscribers can subscribe to exact strings or use wildcards (finance/payment/#) to receive multiple related events. Topic trees are administered with MQSC or the administrative REST API: define topic objects, set authority, and control whether publishing is allowed from remote queue managers via clustered topics or pub/sub routing.

Pub/sub inherits MQ reliability: persistent messages survive restarts; transactional publish participates in syncpoint like queue puts. Fan-out increases total message volume—one publish with ten subscribers may create ten durable copies—so capacity planning includes subscriber count and message size. On z/OS, pub/sub has been used for years to broadcast market data, configuration changes, and internal signals alongside traditional queues.

Event-Driven Architecture Patterns

Several patterns recur in MQ-backed event systems. Event notification is the simplest: publisher emits a lightweight event; subscribers fetch details from a database or API if needed (avoid huge payloads on the bus). Event-carried state transfer puts enough data in the message that subscribers need not call back—convenient but couples schema evolution to every subscriber.

Event sourcing (as a broader architecture) stores state as a sequence of events; MQ may transport those events between services even if the system of record is an event store or Db2 tables. Saga-style distributed transactions use a series of commands and events across queues to coordinate long-running business processes with compensating actions when a step fails.

Outbox pattern pairs database commits with publishing: the application writes a row to an outbox table in the same transaction as business data; a separate relay process publishes from the outbox to MQ topics. That avoids "dual write" races where the database commits but the message never publishes. On mainframe, similar patterns appear with Db2 and batch publishers draining staging tables to topics.

IBM MQ as an Event Backbone

An event backbone is shared infrastructure that many applications use to publish and subscribe safely. IBM MQ queue managers often play this role in enterprises that already depend on MQ for core banking, payments, and insurance flows. Strengths include mature operations tooling, z/OS coupling facility high availability, granular security, and bridging to cloud via channels and containerized queue managers.

MQ as a backbone does not replace every specialized streaming platform. Very high-volume analytics streams with long retention may also use Kafka or similar alongside MQ. Many shops use MQ for authoritative, low-latency, transactional events that must not be lost, and mirror selected topics to data platforms for analytics. CICS and batch programs can publish and subscribe through the same topic tree as Java and Node.js services, which supports gradual modernization without ripping out the mainframe event fabric.

Governance matters: topic catalogs, schema versioning (Avro, JSON schema, copybook versions), and ownership per domain reduce chaos. Line-of-business topic prefixes, test versus production topic trees, and separation of command queues from event topics keep event-driven growth manageable for beginners joining a mature estate.

Introduction to Retained Publications

Retained publications address a common pub/sub problem: a subscriber starts after the last event was published and would otherwise hear nothing until the next event. With retention enabled on a topic (per product configuration and topic settings), the queue manager keeps the latest retained message. When a new subscription is created, the subscriber can receive that last message immediately—useful for current exchange rates, feature flags, or latest product catalog version.

Retention is not a full message history. It is typically the latest publication per retained topic scope, not an archive of every change. Historical analysis still belongs in databases or log pipelines. Administrators should understand storage impact and when retained messages expire or are replaced by newer publishes. Beginners should contrast retained pub/sub with reading a backlog from a queue: retention is about state snapshot for late joiners, not replay of all past events unless you design a separate replay mechanism.

Combine retained topics with non-retained high-volume feeds carefully. Operational runbooks should document which topics are retained and what downstream systems assume about freshness when they restart.

Queues, Topics, and When to Use Each

Mainframe and Hybrid Event Flows

z/OS applications publish business events from CICS, IMS, or batch using the same topic strings as distributed publishers, subject to security and naming standards. Channels connect hub queue managers to spokes in cloud regions. Schema translation layers map EBCDIC copybooks to UTF-8 JSON for cloud subscribers while the mainframe retains canonical formats. Event-driven modernization often starts by publishing facts the mainframe already knows—posted transactions, updated balances—rather than replicating entire databases.

Error handling in event systems includes dead-letter queues for failed processing, poison message quarantine, and correlation IDs to trace causality across topics. Because many subscribers process the same event, idempotent handlers and deduplication keys (business event ID in the payload) prevent duplicate side effects when messages are redelivered.

Key Terms

• Publication — Message published to a topic.
• Subscription — Registration of interest in a topic (or wildcard).
• Subscriber queue — Queue that receives messages for a subscription.
• Topic string — Hierarchical name identifying the event category.
• Event backbone — Shared messaging fabric for enterprise events.
• Retained publication — Last message kept for late-joining subscribers.
• Idempotent consumer — Handler safe if the same event is processed more than once.

Tutorial: Define a Topic and Subscription with MQSC

The following MQSC creates a topic hierarchy node, a subscription for an audit application, and displays the resulting subscriber queue. Adjust names to your standards and run on a lab queue manager. Publishing applications use the topic string; subscribers get from the queue shown in the display.

1
2
3
4
5
6
7
8
9
* Topic for retail order placed events (queue manager QM1)
DEFINE TOPIC('ORDER.PLACED.TOPIC') TOPICSTR('retail/order/placed') +
  DESCR('Order placed business event')
DEFINE SUB('AUDIT.ORDER.PLACED.SUB') TOPICSTR('retail/order/placed') +
  DEST('AUDIT.ORDER.PLACED.Q') +
  DESCR('Audit trail subscriber')
DEFINE QLOCAL('AUDIT.ORDER.PLACED.Q') REPLACE
DISPLAY SUB('AUDIT.ORDER.PLACED.SUB') ALL
DISPLAY TOPIC('ORDER.PLACED.TOPIC') ALL

After definitions, a publisher puts to topic string retail/order/placed (or resolves the topic object). The queue manager places a copy on AUDIT.ORDER.PLACED.Q for the audit consumer. Additional subscribers can subscribe to the same topic string with different destination queues—fulfillment, analytics, and email services each get their own copy. To experiment with retention, consult IBM MQ 9.x documentation for RETAIN and related topic attributes on your release; enable only on topics where a single latest value is correct.

Explain Like I'm Five: Event-Driven Systems

At school, when the bell rings, that is an event. Lots of people hear the same bell and do different things: kids go outside, teachers take attendance, the office notes recess time. Nobody gave a personal command to each person—the bell announced something happened. IBM MQ topics are like the school bell system for programs: one program rings the bell (publishes), and every program that signed up to care (subscribed) hears it and acts. A command is more like the teacher telling one student, "Please erase the board"—only that student should do it.

Practice Exercises

Work through these to connect event-driven ideas to MQ objects you can define in a lab.

Exercise 1: Event or Command?

Classify each as event or command and choose queue or topic: (a) send SMS receipt to one notification service, (b) announce policy renewal to billing, CRM, and data warehouse, (c) debit account once in ledger, (d) broadcast FX rate update to ten front-end apps. Explain duplicate-handling needs for (b) and (d).

Exercise 2: Draw Pub/Sub Fan-Out

Sketch one publisher and three subscribers on topic retail/order/placed. Label topic string, subscription names, and subscriber queues. How many messages exist after one publish if all three subscriptions are active?

Exercise 3: Retained Topic Scenario

A mobile app subscribes to config/features on startup. The last feature flag publish was an hour ago. Would retention help? What misunderstanding might occur if the team expects full history from retention alone?

Exercise 4: Backbone Governance

Propose a topic naming convention with three levels (domain/entity/action) and two rules for who may publish to production topics. Write how you would document schemas for mainframe and cloud subscribers.

Test Your Knowledge