Message Ordering

Message ordering answers a question every integration architect asks: will event B always arrive after event A? IBM MQ gives strong local ordering on a single queue under controlled conditions, but it is not a global timeline service like some event logs. Priority, competing consumers, syncpoint backout, channel failure, and message groups all change what applications actually see. Beginners assume one queue equals strict worldwide sequence—that breaks the moment you scale consumers. This page explains FIFO within priority, the Priority and MsgSeqNumber fields, message groups and logical order, partitioning patterns for scale, pub/sub ordering caveats, and how to add application-level sequence keys when MQ defaults are not enough.

FIFO on a Single Queue

The default mental model is first-in-first-out: the oldest message on the queue is the next available for MQGET when priorities are equal and no special get options apply. The queue manager maintains internal linkage; CURDEPTH and browse can show order approximately but getters should use MQGET, not browse, for processing. FIFO is per queue, not per enterprise—two queues feeding one service have no coordinated order unless the application enforces it.

Priority Explained

Priority 9 is urgent relative to Priority 0 on the same queue. Operations sometimes reserve 9 for control messages and 0–5 for bulk traffic. Mixing all traffic at priority 5 loses the benefit. Consumers still compete—priority affects queue position, not which consumer wins the race. On z/OS and distributed queue managers, confirm whether DEFPRTY on the queue sets a default when the application leaves priority unset.

Message Groups and Logical Order

Large payloads split across multiple messages share a GroupId; MsgSeqNumber orders pieces 1, 2, 3. A consumer opens the group with appropriate MQGMO options (such as MQGMO_LOGICAL_ORDER in the Application Programming Reference) so MQ delivers pieces in sequence even after partial failure. Groups help when a single MQ message size limit forces segmentation. Closing a group incorrectly leaves consumers waiting for the next segment—monitor for stuck readers.

Multiple Consumers Break Global Order

Scale-out pattern: ten instances MQGET from ORDERS.IN. Throughput rises; global order falls. Message 100 might finish before message 99 if instance 3 is faster. If business rules require strict order per customer, partition: ORDERS.CUSTOMER.AA through ORDERS.CUSTOMER.ZZ keyed by hash, or embed CustomerId and sequence in payload and reject out-of-order processing in the app. Kafka partitions solve a similar problem; MQ uses queue topology and design.

Backout, Redelivery, and Poison Messages

MQBACK returns a message to the queue. Newer messages may be consumed first while the backed-out message waits. BOTHRESH routes chronic failures to a backout queue—order on the main queue moves on without the poison message. That is correct for throughput but wrong if you assumed strict FIFO including failures. Idempotent consumers and sequence checks handle redelivery.

Channels and Cross-Site Order

Messages on a transmission queue generally forward in order per queue, but multiple putting applications, channel restarts, and multiple paths can reorder at the receiver relative to source wall-clock time. For cross-datacenter strict order, use one sequence stream per business key or accept eventual order with reconciliation.

Pub/Sub Ordering

Topics fan out to many subscribers. Each subscriber queue or subscription has its own order. Subscriber A and Subscriber B are not ordered relative to each other. Durable subscriptions retain messages; non-durable subscribers miss messages while offline—different semantics from point-to-point FIFO.

Tutorial: Priority and Sequence in Payload

1
2
3
4
5
6
7
8
9
10
11
Put options (conceptual):
  MD.Priority = 9          /* control message */
  MD.Priority = 0          /* bulk batch */
 
Application-level order (JSON in body):
  { "customerId": "C100", "seq": 42, "event": "SHIP" }
  Consumer: reject or buffer if seq != lastSeq+1 for C100
 
Partition pattern:
  hash(customerId) % 32 -> ORDERS.PART.00 .. ORDERS.PART.31
  One consumer per partition queue -> order per customer

Explain Like I'm Five: Message Ordering

Everyone lines up for ice cream in one line—that is FIFO. If the teacher lets VIP kids cut in front, priority changed the line. If three windows serve the same line at once, who gets ice cream first is not the same as who joined the line first—that is multiple consumers.

Practice Exercises

Exercise 1: Design Partitions

100,000 customers, order must be per customer, 8 consumers. Sketch queue names and routing.

Exercise 2: Priority

Bulk at 0, alerts at 9. Could a bulk message starve alerts? Could alerts block bulk forever?

Exercise 3: Backout

Message fails three times, goes to BOQNAME. Describe order on main queue for messages 4–10.

Frequently Asked Questions

Test Your Knowledge