Message Queue vs Message Broker vs Event Broker: What Is the Difference?
A message queue is a buffer that holds messages until a consumer takes them. Each message is delivered to exactly one consumer. A message broker is the server that hosts queues and topics and routes each message from its producer, the service that sends it, to its consumers, the services that receive it. An event broker is a broker built for publish-subscribe events. Many consumers read the same event independently, and they can replay past events from stored history.
The three terms describe three levels, not three competing products. A queue is a data structure. A broker is the software that manages many queues. An event broker is a broker whose storage is a log rather than a queue. The product families themselves, from in-memory brokers to cloud services and enterprise buses, are listed in Types of Message Brokers.
Message queues: one message, one consumer
A queue gives point-to-point delivery, which means a message has one sender and one receiver. Amazon SQS is a queue service with no broker for you to run. A producer sends a message and one worker receives it. SQS then hides the message from other workers for a visibility timeout, 30 seconds by default, until the worker deletes it. A message stays in a standard queue for 4 days by default and 14 days at most.
A RabbitMQ queue behaves the same way inside a broker. The broker pushes each message to one consumer and removes it once the consumer acknowledges it. After that, the message is gone, and a second consumer cannot ask for it. Use a queue when a piece of work must be done once: sending an email, resizing an image, charging a card. The reasons queues appear in almost every scalable design are covered in What is a message queue and why are queues used in scalable system design?.
Message brokers: the server that hosts and routes
A message broker hosts many queues and topics and decides where each message goes. RabbitMQ routes through exchanges. A producer publishes to an exchange, and bindings, which are rules that match on a routing key or a header, copy the message into one or more queues. Apache ActiveMQ implements JMS (Java Message Service, the standard Java API for messaging) and supports both queues and topics. Azure Service Bus is a managed broker with queues, topics, sessions for ordering, and dead-letter queues, which hold messages that could not be processed.
A broker's topic gives fan-out, which means one message is copied to every current subscriber. The difference from an event broker is what happens next. The broker deletes the message once each subscriber has consumed its copy. A subscriber that joins tomorrow does not see today's messages.
Event brokers: a log that many readers can replay
An event broker stores events in an append-only log. Each consumer keeps its own position in that log, called an offset. Apache Kafka is the most common example. A topic is split into partitions, each partition is an ordered log, and Kafka keeps events for a retention period, 7 days by default, whether or not anyone has read them. A new consumer group can start from offset zero and reprocess the whole week.
Apache Pulsar separates serving from storage (Apache BookKeeper) and supports tiered storage in object stores, so retention can run to months. Amazon EventBridge is a serverless event bus that routes events to targets through rules. Its archive and replay feature re-sends stored events on request. Solace PubSub+ is an event broker used in finance for low-latency fan-out over topic hierarchies. In each case, reading an event does not remove it.
Comparison table
| Message queue | Message broker | Event broker | |
|---|---|---|---|
| Delivery model | Point-to-point: one consumer per message | Point-to-point plus fan-out through topics | Fan-out: every consumer group reads every event |
| Retention | Until consumed or expired (SQS: 14 days maximum) | Until every subscriber has consumed it | Fixed age or size, regardless of reads (Kafka: 7 days by default) |
| Ordering | Per queue with one consumer; SQS FIFO per message group | Per queue; lost across competing consumers | Per partition, guaranteed |
| Replay | No | No (except RabbitMQ Streams) | Yes, from any offset |
| Typical use | Background jobs, work distribution | Routing between services, request-reply | Event sourcing, analytics, audit logs |
Where Kafka sits
Kafka is a distributed log used as an event broker. People also call it a message broker because it does the broker's job. Producers send, consumers receive, and the server between them stores and routes. The difference is in what is stored and when it is deleted. Kafka deletes by age or size, never because a message was read. Consumers pull from an offset instead of being pushed messages.
Kafka can imitate a queue with a consumer group, in which each partition is read by exactly one consumer in the group. Even then, the message stays in the log for every other group. That is why one order-placed event can feed the payment service, the inventory service, and an analytics service added a year later.
Which one the interviewer means by "put a queue here"
The interviewer almost always means "decouple these two parts and absorb bursts". State that purpose first. "I will put a queue between the API and the workers, so a spike of 10,000 uploads per minute is stored and processed at the workers' pace". Then say which kind you are choosing and why.
If each message must be processed once by one worker, say queue and name SQS or a RabbitMQ queue. If several services need the same event, or you may need to reprocess history, say event broker and name Kafka. Finish with the ordering guarantee and the retention you rely on. Those are the two follow-up questions. A full design is worked through in How to Design a Message Queue Architecture for System Design Interviews.
How to Prepare
- Learn one product per column of the table above (SQS, RabbitMQ, Kafka). State its delivery model, retention, and ordering guarantee without notes.
- Practice the choice out loud for an email sender, an order pipeline, and a click stream. Name queue or event broker and give the one reason.
- Know the failure questions: a consumer that crashes mid-message, a message that cannot be processed, and a consumer group that falls behind.
- Study the messaging chapters in Grokking System Design Fundamentals, which cover queues, pub-sub, and delivery guarantees with diagrams.
- Apply the pattern in full designs with Grokking the System Design Interview, where notification, feed, and order systems each place a broker for a stated reason.
GET YOUR FREE
Coding Questions Catalog
$99
$197
$72
