12 Core Principles of Message Queues (MQ) – A Comprehensive Summary

Message queues have become a core mechanism for distributed applications, internal communication, and high‑concurrency scenarios such as flash sales, offering low coupling, reliable delivery, broadcasting, flow control, and eventual consistency.

Regardless of whether you use RabbitMQ, RocketMQ, ActiveMQ, Kafka, or other solutions, they share basic principles, terminology, and mechanisms; this summary aims to help you quickly understand MQ technology.

1. Producer, Consumer, and Queue

Producer: sends messages to the message queue.

Consumer: receives messages from the message queue.

Broker: the server side of the MQ (originating from Apache ActiveMQ) that transports messages from sender to receiver.

Queue: a FIFO storage area where messages are kept until consumed; once processed, the message is removed.

2. Design considerations for the broker

1) Message dumping: deliver messages at an appropriate time or use auxiliary means to ensure eventual delivery.

2) Provide a standard paradigm and common pattern to satisfy decoupling, eventual consistency, and traffic‑shaping needs.

3) Conceptually, the broker acts as a two‑step RPC: the sender delivers to the broker, which then forwards to the receiver.

In practice this results in two RPC calls plus one dump; with consumer acknowledgment it becomes three RPC calls.

3. Point‑to‑Point (Queue) Model

The point‑to‑point model enables direct communication between a producer and a consumer.

Roles:

Queue (Message Queue)

Sender (Producer)

Receiver (Consumer)

Each message is sent to a specific queue; the consumer pulls messages from that queue. Queues can reside in memory or be persisted until consumed or timed out.

Features

Each message is consumed by a single consumer.

Producers and consumers are temporally decoupled.

Consumers must acknowledge successful receipt.

4. Publish‑Subscribe (Topic) Model

Roles:

Topic (Subject)

Publisher

Subscriber

Multiple publishers send messages to a topic, and the system delivers those messages to all subscribed consumers.

Features

A single message can have multiple consumers.

Publishers and subscribers have a temporal dependency.

Subscribers must create a subscription before they can receive messages.

Subscribers need to stay online to consume messages.

5. Differences between Point‑to‑Point and Publish‑Subscribe

In the point‑to‑point model, a message sent to a queue is received by only one consumer; in the publish‑subscribe model, a message sent to a topic is received by all subscribers of that topic.

6. Message ordering guarantee

Using the FIFO nature of the queue model ensures that messages are processed in the order they were sent.

7. ACK mechanism

Consumers acknowledge messages after successful processing; if a consumer crashes without sending an ACK, the broker will redeliver the message to another consumer.

8. Design for eventual consistency

It relies on “record” and “compensation” strategies: local transactions store business changes and notification messages together, RPC delivers to the broker, and upon successful broker persistence the local message can be cleared; otherwise, a retry mechanism ensures delivery.

9. Transaction support for messages

Message send/receive can participate in a transaction scope; if any processing fails, the transaction rolls back and the message returns to the queue for reprocessing.

10. Message persistence

Enabling persistence ensures that messages survive broker restarts, preventing loss of critical business data.

11. High availability of message queues

Single‑instance deployments are vulnerable to failures; high‑availability solutions include RabbitMQ mirrored clusters, ActiveMQ with LevelDB + ZooKeeper, and Kafka’s replication mechanism.

12. MQ selection and application scenarios

For detailed guidance on choosing the right MQ and its use cases, refer to the linked high‑concurrency architecture series.