Fundamentals of Message Queues: Producers, Consumers, Brokers, and Messaging Models

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, broadcast, flow control, and eventual consistency.

Regardless of the implementation—RabbitMQ, RocketMQ, ActiveMQ, Kafka, etc.—the basic concepts, terminology, and mechanisms are similar, and this article summarizes them to help readers quickly understand queue technology.

1. Core components

Producer: sends messages to the queue.

Consumer: receives messages from the queue.

Broker: the server side of the MQ that transports messages from producers to consumers.

Queue: a FIFO storage area where messages are kept until consumed.

2. Design considerations for a broker

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

2) Define a common paradigm to achieve decoupling, eventual consistency, and load‑shaping.

3) Conceptually, a broker acts as a two‑step RPC: the producer sends to the broker, which forwards to the consumer; with acknowledgments this becomes three RPC steps.

3. Point‑to‑point (P2P) model

The P2P 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 consumption or timeout.

Characteristics

Each message is consumed by only one consumer.

Senders and receivers are temporally decoupled.

Consumers must acknowledge successful processing.

4. Publish‑Subscribe (Pub/Sub) model

Roles

Topic

Publisher

Subscriber

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

Characteristics

One message can have multiple consumers; all subscribers receive the published message.

Publishers and subscribers have a temporal dependency.

Subscribers must create a subscription before they can consume messages from a topic.

Subscribers need to stay online to receive messages.

5. Differences between P2P and Pub/Sub

In P2P, a producer sends a message to a queue and only one consumer receives it; in Pub/Sub, a publisher sends to a topic and all subscribers to that topic receive the message.

6. Message ordering

The FIFO nature of a queue guarantees message order when using the queue model.

7. ACK mechanism

Consumers acknowledge messages after successful processing; if a consumer crashes without sending an ACK, the broker treats the message as unprocessed and re‑delivers it to another consumer.

8. Designing for eventual consistency

Use a “record and compensate” approach: local transactions store business changes and notification messages together; after the broker successfully persists the message, the local transaction can be cleared; otherwise, a retry mechanism ensures reliability.

9. Transaction support

Message send/receive can participate in a transaction so that if processing fails, the transaction rolls back and the message returns to the queue.

10. Persistence

Enabling persistence ensures that messages survive broker restarts and can be recovered without loss.

11. High availability

Single‑instance brokers are a single point of failure; solutions include RabbitMQ mirrored clusters, ActiveMQ with LevelDB+ZooKeeper, and Kafka replication to provide HA.

12. Queue selection and scenarios

For detailed guidance on choosing a message queue and its application scenarios, refer to the linked high‑concurrency architecture series.