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

The author regards message queues, caches, and sharding as the three swords for handling high concurrency and has experience with ActiveMQ, RabbitMQ, Kafka, and RocketMQ. This article shares seven classic message‑queue application scenarios.

1 Asynchronous & Decoupling

In a user‑registration service, sending an SMS directly couples the core service with a non‑core function, causing latency and maintenance issues. By publishing a message to a queue, the service returns immediately, achieving asynchronous processing and decoupling the SMS task.

Asynchronous: the registration service saves user data, pushes a message, and returns instantly, avoiding long‑lasting operations.

Decoupling: a separate task service consumes the message and invokes the SMS service, reducing system coupling.

2 Traffic Smoothing (Peak Shaving)

During sudden request spikes, direct database writes can overload resources. By first updating a cache and then publishing a message, a consumer processes the writes at a controlled rate, stabilizing the front‑end and protecting the database.

3 Message Bus

Similar to a hardware data bus, a message queue acts as a central communication hub. In an order‑processing workflow (creation, splitting, ticketing, award calculation), each subsystem publishes and consumes messages via the bus, avoiding direct inter‑service calls.

4 Delayed Tasks

For orders that remain unpaid, a delayed message can automatically cancel them after a timeout. The producer sends a delayed message to RocketMQ, which delivers it when the delay expires.

<code>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);
</code>

RocketMQ 4.x supports 18 predefined delay levels; RocketMQ 5.x allows arbitrary delay times via additional APIs.

5 Broadcast Consumption

Broadcast consumption delivers each message to all consumers, useful for push notifications and cache synchronization.

5.1 Push Notifications

In a ride‑hailing app, the dispatch system publishes order assignments; driver apps maintain long‑lived TCP connections and receive broadcast messages to display new orders.

5.2 Cache Synchronization

Applications often keep local caches (e.g., HashMap, Caffeine). When dictionary data changes, a broadcast message triggers each node to refresh its cache, ensuring consistency across the cluster.

6 Distributed Transactions

In an e‑commerce payment flow, multiple downstream services (logistics, points, cart) must stay consistent with the order transaction. Traditional XA transactions suffer performance penalties, while plain messages risk inconsistency.

RocketMQ transactional messages provide a two‑phase commit: the producer sends a "half" message, executes local transaction logic, then commits or rolls back the message based on the local outcome. The broker delivers the message only after a commit, achieving eventual consistency.

7 Data Hub

Kafka can serve as a data hub, routing logs or events to various specialized systems such as HBase, Elasticsearch, Spark, or OpenTSDB. The pipeline consists of a log‑collecting client, Kafka for durable storage, and downstream processors (e.g., Logstash, Hadoop) that consume and forward data to target systems.