Backend Development 9 min read

Understanding Apache RocketMQ: Domain Model, Communication & Message Patterns

This article explains Apache RocketMQ's core components—including producers, topics, queues, and consumer groups—covers synchronous RPC versus asynchronous messaging, compares point‑to‑point and publish‑subscribe transmission models, and highlights their suitable scenarios and trade‑offs.

Architecture & Thinking
Architecture & Thinking
Architecture & Thinking
Understanding Apache RocketMQ: Domain Model, Communication & Message Patterns

1 Domain Model

Apache RocketMQ is a typical distributed message middleware product that uses asynchronous communication and a publish‑subscribe transmission model. It features simple system topology and weak upstream‑downstream coupling, making it suitable for decoupling, traffic smoothing, and similar scenarios.

As shown, the message lifecycle in RocketMQ consists of three parts: production, storage, and consumption.

Producer produces messages and sends them to the RocketMQ server.

Messages are stored in topics on the server.

Consumers subscribe to topics to consume messages.

1.1 Message Production

Producer: the runtime entity that generates messages, usually integrated in the upstream of the business call chain.

1.2 Message Storage

Topic: a grouping container for message transmission and storage, composed of multiple queues.

MessageQueue: the actual unit container, analogous to partitions in other MQs, providing sequential storage.

Message: the smallest immutable transmission unit.

1.3 Message Consumption

ConsumerGroup: an independent consumption identity group defined in RocketMQ's pub/sub model, managing multiple consumers that share the same logic and configuration for horizontal scaling.

Consumer: the runtime entity that consumes messages, usually downstream of the business call chain, and must belong to a consumer group.

Subscription: rule configuration for message filtering, retry, and consumption progress, managed at the consumer‑group level; all subscription data is persisted except filter expressions.

2 Communication Methods

In distributed system architecture, remote communication between modules can be synchronous RPC or asynchronous middleware‑based communication.

2.1 Synchronous RPC Call Model

In the synchronous RPC model, a request is sent directly from the caller to the callee, and the caller waits for an immediate response to determine success.

2.2 Asynchronous Communication Model

In asynchronous messaging, subsystems do not need strong coupling; the caller converts the request into an asynchronous event (message) and sends it to a middle proxy. The middleware ensures task execution, offering a simple star‑shaped topology, upstream/downstream decoupling, and capacity smoothing.

Simple system topology: unified middle‑proxy communication creates a star‑shaped structure that is easy to maintain.

Upstream/downstream decoupling: components can be upgraded independently without affecting each other.

Capacity smoothing: avoids overload during traffic peaks.

3 Message Transmission Models

Mainstream message middleware uses point‑to‑point and publish‑subscribe models; RocketMQ is no exception.

3.1 Point‑to‑Point

In the point‑to‑point model, each message can be consumed by only one consumer; after consumption it is removed from the queue. The producer and consumer are independent, and the producer can send messages regardless of consumer availability. This model suits scenarios requiring exactly‑once consumption, such as order processing or payment confirmation.

3.2 Publish‑Subscribe (Broadcast)

In the publish‑subscribe model, a message can be consumed by multiple consumers. The producer publishes the message to a topic, and all consumers subscribed to that topic receive it. The producer does not need to know the number of consumers. This model is suitable for broadcasting notifications, log collection, and similar use cases.

3.3 Scenarios, Advantages and Disadvantages

Point‑to‑point ensures reliable delivery but has limited scalability, making it less suitable for large numbers of consumers. Publish‑subscribe offers good scalability and can support many consumers simultaneously, but messages may be consumed multiple times, requiring additional handling mechanisms.

3.4 Practical Cases

Point‑to‑point: in an order processing system, each order operation (creation, payment, etc.) is an independent message, ensuring isolated processing.

Publish‑subscribe: in a real‑time notification system, new events are published to a topic, and all subscribed clients receive the notification instantly.

5 Summary

Understanding RocketMQ's basic components, communication methods, and message transmission models.

Distributed SystemsBackend DevelopmentMessage QueuerocketmqPub/SubAsynchronous Communication
Architecture & Thinking
Written by

Architecture & Thinking

🍭 Frontline tech director and chief architect at top-tier companies 🥝 Years of deep experience in internet, e‑commerce, social, and finance sectors 🌾 Committed to publishing high‑quality articles covering core technologies of leading internet firms, application architecture, and AI breakthroughs.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.