Retailers sell through web, mobile, marketplaces, and thousands of stores—each producing orders that must allocate inventory, reserve payment, pick in a warehouse or store, ship, and handle returns. Peak events (Black Friday, product drops) can multiply order rate tenfold for hours. IBM MQ lets the digital storefront accept orders while fulfillment systems consume at their own pace, and it carries status updates back to customers and analytics. This tutorial maps omnichannel order capture, OMS orchestration queues, warehouse management (WMS) integration, inventory allocation request/reply, payment handoff, ship confirm pub/sub, returns pipelines, and store-to-hub messaging patterns suitable for beginners designing their first retail estate.
When checkout completes, the ecommerce service validates cart, authorizes payment (often synchronous with payment provider), then MQPUTs ORDER.CREATED with order ID, line items, and ship-to address. Persistence is YES. The HTTP response to the shopper can return “order accepted” once the put commits under syncpoint with the order database row—exact choreography varies by retailer. If WMS is down, depth on ORDER.CREATED grows; marketing may throttle promotions when depth exceeds threshold.
12345DEFINE QLOCAL('ORDER.CREATED') MAXDEPTH(2000000) DEFPSIST(YES) DEFINE QLOCAL('WMS.PICK.REQUEST') MAXDEPTH(500000) DEFPSIST(YES) DEFINE QLOCAL('ORDER.SHIP.CONFIRM') MAXDEPTH(500000) DEFPSIST(YES) DEFINE QLOCAL('RETURNS.REQUEST') MAXDEPTH(100000) DEFPSIST(YES) * Size MAXDEPTH for peak day + safety; monitor CURDEPTH hourly in peak season
The order management service GETs ORDER.CREATED, splits lines by fulfillment node (DC versus store), and puts WMS.PICK.REQUEST per node. Scatter-gather appears when one order ships from three warehouses—three request messages, aggregator waits for all ship confirms before closing order state. Correlation uses order ID in payload and optionally MsgId per line request. OMS updates state machine: ALLOCATED, PICKING, SHIPPED, RETURNED.
| Queue (example) | Producer | Consumer |
|---|---|---|
| ORDER.CREATED | Web/mobile | OMS |
| INVENTORY.CHECK | OMS | Inventory service |
| WMS.PICK.REQUEST | OMS | WMS adapter |
| ORDER.SHIP.CONFIRM | WMS | OMS / notify |
| RETURNS.REQUEST | Returns portal | Returns service |
Allocation prevents overselling. OMS sends request/reply to INVENTORY with SKU and quantity; inventory reserves stock in Db2 or dedicated engine and replies RESERVED or DENIED. Short timeouts during flash sales cause high denial rates—depth on ORDER.CREATED is healthier than HTTP thread pools blocked on inventory. Some retailers publish INVENTORY.LOW.STOCK to topics for pricing and merchandising subscribers.
Point-of-sale systems in stores may use a local queue manager that batches ORDER.STORE.SALES to the enterprise hub overnight or in near-real-time. Buy-online-pickup-in-store (BOPIS) needs low latency from store inventory updates to web availability—often request/reply or frequent small messages over channel with tuned HBINT. Store connectivity outages should buffer on spoke disk until channel returns.
Payment capture may mirror banking patterns: PAYMENT.AUTH.REQUEST queue to payment gateway adapter. Settle messages later for capture versus auth-only. Fraud scoring can subscribe to ORDER.CREATED topic copy while OMS waits on HOLD queue until score returns—careful timeout design avoids orders stuck in limbo.
WMS puts ship confirm with tracking number. OMS updates database idempotently by order ID + shipment ID, then publishes ORDER.SHIPPED topic for email/SMS/push subscribers. Duplicate ship confirms must not send two emails—consumer checks shipment ID table. Non-persistent notifications are rare; customers expect proof of shipment.
Returns portal puts RETURNS.REQUEST; warehouse expects different dock and QA process. Refund triggers payment queue after goods received. Keeping returns off forward pick queues protects peak season throughput. DLQ on returns still needs finance oversight—wrong refund is customer-visible.
Orders are tickets on a rail in the kitchen (WMS). The waiter (web site) keeps taking orders and pinning tickets to the rail even when cooks are busy. IBM MQ is the rail. Cooks pull tickets when ready. The customer gets “order received” before food is cooked—that is decoupling.
When you click “buy,” your order goes into a waiting line at the toy factory. IBM MQ is that line. The website tells you “got your order” right away. Workers take orders from the line when they can. When the toy ships, another message tells your parents’ email app to say it is on the way.
Map BOPIS flow with web, OMS, store inventory, and customer pickup notification.
Design idempotency for ship confirm with orderId and shipmentId.
Estimate MAXDEPTH if peak is 500 orders/sec for 2 hours and WMS processes 200/sec.
1. Peak ecommerce traffic is absorbed by:
2. Ship confirm should be:
3. Returns queues should be:
4. OMS state authority is in: