The message router is one of the classic Enterprise Integration Patterns documented by Hohpe and Woolf: a single input channel fans out to one or many outputs based on rules that can be as simple as message type or as complex as product line, country code, and risk score combined. IBM MQ provides durable queues and transactional gets and puts; the router is the program or integration flow sitting between those queues making decisions. Retail order feeds use routers to send grocery items to fulfillment queue A and digital gift cards to queue B without the order entry system knowing every downstream system. Beginners sometimes create twenty queues upstream instead of one router and duplicate business rules in every producer—when the rule changes, twenty programs need redeploying. This tutorial explains router responsibilities, static versus dynamic rules, implementing routers in Java, .NET, or App Connect, transactional boundaries, idempotency when redelivery happens, comparison with content-based router specialization, performance and back-pressure, monitoring routed message counts per destination, and failure modes when one output queue is full.
Producers put to ROUTER.IN. The router application uses MQGET with syncpoint, evaluates rules, MQPUT to TARGET.A, TARGET.B, or dead-letter path. Consumers on each target queue process independently. The router may copy the same message body to multiple targets (one-to-many) or choose exactly one target (switch). Clarify business requirement before coding—accounting audits often forbid silent duplicate delivery.
| Variant | Behavior | MQ note |
|---|---|---|
| Recipient list | Copy to all listed queues | Multiple PUTs in one UOW |
| Content-based | One destination per rules | See dedicated tutorial |
| Dynamic | Lookup table drives target | Refresh table without restart |
| Wire tap | Route plus audit copy | Extra PUT to audit queue |
123456789101112BEGIN syncpoint GET from ROUTER.IN (wait, syncpoint) Parse message / headers IF orderType = 'DIGITAL' THEN PUT to ORDERS.DIGITAL.Q ELSE IF orderType = 'STORE' THEN PUT to ORDERS.STORE.Q ELSE PUT to ORDERS.UNKNOWN.Q END COMMIT syncpoint ON FAILURE: BACKOUT — message returns to ROUTER.IN
Backout leaves the message available for retry; repeated failures may hit backout threshold and land on DLQ—configure DLQ and monitor depth. Router should log correlationId and chosen destination for support.
The router is a traffic director at a highway junction reading each car's destination sign and pointing left or right. MQ roads are queues; the director is your integration program.
Centralizing rules in the router simplifies producers but makes the router a bottleneck and single point of failure—scale router instances as competing consumers on ROUTER.IN only if messages are independent; otherwise partition input queues by shard key. Large messages increase CPU parsing XML or JSON—consider reference data in headers (MsgType field in MQMD or user properties) instead of parsing full body when possible.
After backout and redelivery, router may re-put to targets unless you detect duplicate messageId. Downstream idempotent consumers or deduplication store reduce duplicate side effects. At-least-once messaging is normal; exactly-once end-to-end needs coordination beyond basic router.
A message router is the teacher who takes one pile of worksheets and puts spelling papers in one tray and math papers in another tray so the right helper can grade them.
Draw router diagram for one input and three outputs with DLQ path.
Define syncpoint boundaries for one-to-many copy router.
List three metrics you would alert on for a payment router.
1. Message router decides:
2. Router with syncpoint:
3. MQ cluster is:
4. Static router rules are in: