7 Real-World Message Queue Patterns Every Backend Engineer Should Know

1 Asynchronous & Decoupling

In an e‑commerce user service, after a user registers, a SMS needs to be sent. Previously the registration and SMS logic were tightly coupled, causing latency and maintenance issues when the SMS channel was unstable or changed.

Refactoring with a message queue makes the registration service publish a message and return immediately, while a separate task service consumes the message to send the SMS, achieving both asynchronous processing and decoupling.

2 Peak Smoothing

During traffic spikes, sudden request bursts can overload databases and CPU/IO. By publishing order‑modification events to a queue (e.g., MetaQ) and letting a consumer persist them at a controlled rate, the system smooths the load, keeping the front‑end stable.

3 Message Bus

A message bus works like a motherboard data bus, providing a standard communication interface so services do not talk directly. In a lottery order system, a scheduling center maintains order state and exchanges information with downstream services (ticketing, prize calculation) via a message queue, keeping services loosely coupled.

4 Delayed Tasks

When a user places an order but does not pay within a timeout, the order should be automatically cancelled. Using delayed messages in RocketMQ, the order service publishes a delayed message; when the delay expires, the consumer checks the order status and cancels unpaid orders.

Message msg = new Message();
msg.setTopic("TopicA");
msg.setTags("Tag");
msg.setBody("this is a delay message".getBytes());
// set delay level 5 (1 minute)
msg.setDelayTimeLevel(5);
producer.send(msg);

RocketMQ 4.x supports 18 delay levels; RocketMQ 5.x allows arbitrary timestamps via dedicated APIs.

5 Broadcast Consumption

Broadcast consumption delivers each message to every consumer in a cluster, ensuring at least one consumption per consumer. It is used for message push (e.g., driver‑side order notifications) and cache synchronization across distributed nodes.

01 Message Push

After an order is created, the dispatch system sends a broadcast message. Driver apps maintain long‑lived TCP connections; the push service receives the broadcast and forwards the order to the appropriate driver.

02 Cache Sync

Local caches (HashMap, Guava, Caffeine) improve performance. When dictionary data changes, a broadcast message triggers all nodes to refresh their caches, keeping data consistent.

6 Distributed Transactions

In an e‑commerce transaction, payment must coordinate with downstream services (logistics, points, cart). Traditional XA transactions suffer performance loss. Simple message‑based approaches cannot guarantee consistency, leading to scenarios where messages succeed but orders fail, or vice versa.

RocketMQ’s distributed transaction messages add a two‑phase commit: the producer sends a “half‑transaction” message, executes local transaction logic, then commits or rolls back. The broker delivers the message only on commit, ensuring eventual consistency.

Producer sends message to broker.

Broker persists and returns ACK, marking the message as “pending delivery” (half‑transaction).

Producer executes local transaction.

Producer sends commit/rollback; broker either delivers the message or discards it.

If the broker does not receive a confirmation (e.g., network loss), it performs a message check and the producer re‑sends the final decision.

7 Data Hub

Specialized systems (HBase, Elasticsearch, Storm, Spark, OpenTSDB) often need the same raw data. Using Kafka as a data hub, logs are collected by clients, persisted by Kafka, and consumed by downstream processors (Logstash, Hadoop, etc.), enabling a single source of truth for multiple pipelines.