Message Broker
Middleware that translates messages between different protocols, routes them to the right consumers, and provides guarantees like ordering and delivery. RabbitMQ and ActiveMQ are brokers.
What is Message Broker?
In short
A message broker is middleware that sits between applications and accepts messages from senders, then routes, queues, and delivers them to the right receivers. It decouples producers from consumers so they never talk directly, and it adds guarantees like ordering, persistence, retries, and at-least-once delivery. RabbitMQ, ActiveMQ, and Amazon SQS are message brokers.
What a message broker actually is
When one service needs to tell another service that something happened, the simplest approach is a direct call: service A calls service B over HTTP and waits for a reply. That breaks the moment B is slow, down, or swamped. A message broker fixes this by becoming a middleman. Service A hands its message to the broker and moves on. The broker holds the message and delivers it to service B when B is ready.
The sender is called the producer. The receiver is called the consumer. The broker stores messages in named structures, usually queues or topics, until a consumer picks them up. Because the producer and consumer never touch each other directly, you can restart, scale, or replace either side without the other noticing.
A broker is more than a dumb mailbox. It speaks messaging protocols like AMQP, MQTT, or STOMP so clients written in different languages can interoperate. It decides which consumer gets which message based on routing rules. And it offers delivery guarantees: it can persist messages to disk so they survive a crash, redeliver a message if a consumer fails to acknowledge it, and keep messages in order within a queue.
How it works under the hood
A producer connects to the broker and publishes a message to either a queue or an exchange. In a point-to-point setup, the message lands in a single queue and exactly one consumer in that queue's pool receives it. This is how you spread work across many workers. In a publish-subscribe setup, the message goes to a topic or exchange and the broker fans it out to every subscriber that registered interest.
RabbitMQ uses an exchange-and-binding model. The producer sends to an exchange with a routing key, and bindings decide which queues the message copies into. A direct exchange matches the key exactly, a topic exchange matches wildcard patterns like order.*.created, and a fanout exchange copies to every bound queue. Kafka and other log-based systems instead append messages to a partitioned, ordered log that consumers read at their own offset.
Delivery guarantees come from acknowledgements. After a consumer processes a message it sends an ack, and only then does the broker drop it. If the consumer dies before acking, the broker requeues the message for someone else. This gives at-least-once delivery, which means a message can arrive twice, so consumers must be idempotent. Durable queues and persistent messages are written to disk so a broker restart does not lose anything in flight.
When to use one and the trade-offs
Reach for a message broker when work can happen asynchronously: sending email, generating thumbnails, processing payments after checkout, or spreading a heavy job across a worker pool. It is also the right tool for smoothing traffic spikes, because the queue absorbs a burst that would otherwise overwhelm a slow downstream service. And it is the backbone of event-driven architecture, where many services react to the same event independently.
The cost is operational and conceptual complexity. You now run another stateful system that needs monitoring, capacity planning, and clustering for high availability. Debugging gets harder because a request no longer follows one straight line through your code. You have to handle duplicate messages, poison messages that keep failing, and dead-letter queues for messages that exhausted their retries.
Two broad styles exist. Traditional brokers like RabbitMQ and ActiveMQ delete a message once it is consumed and are great for task queues and complex routing. Log-based platforms like Apache Kafka retain messages for days and let many consumers replay history, which suits high-throughput streaming and analytics. Picking the wrong one, for example using Kafka for a simple job queue, leads to a lot of avoidable plumbing.
A concrete real-world example
Picture an e-commerce checkout. When a customer clicks Pay, the order service writes the order and publishes an order.placed message to the broker, then immediately returns a confirmation page. The customer waits milliseconds, not seconds.
Behind the scenes, several consumers subscribe to that one event. The payment service charges the card. The inventory service decrements stock. The email service sends a receipt. The analytics service records the sale. None of them block the checkout, and if the email service is down for two minutes, its messages simply wait in its queue and get processed when it comes back.
If charging the card fails, the payment consumer does not ack the message, so the broker redelivers it. After a few failed attempts the message moves to a dead-letter queue where an on-call engineer can inspect it. This is exactly the pattern companies like Instacart and DoorDash use to keep the customer-facing path fast while the slow, fallible background work happens reliably out of band.
Where it is used in production
RabbitMQ
The most widely deployed open-source AMQP broker; uses exchanges and bindings for flexible routing, popular for task queues and microservice messaging.
Amazon SQS
Fully managed broker on AWS that scales to millions of messages with standard at-least-once and FIFO exactly-once queues, no servers to run.
Apache Kafka
Log-based broker that retains messages and lets consumers replay them; LinkedIn built it to move trillions of events per day across services.
Apache ActiveMQ
Mature Java broker supporting JMS, AMQP, MQTT, and STOMP; common in enterprise integration where multiple protocols must coexist.
Frequently asked questions
- What is the difference between a message broker and a message queue?
- A message queue is one data structure that holds messages in order until a consumer reads them. A message broker is the full server that manages many queues and topics, handles routing, enforces delivery guarantees, speaks multiple protocols, and persists data. The queue is a feature inside the broker.
- Is Kafka a message broker?
- Yes, but a log-based one. Instead of deleting a message once it is consumed, Kafka keeps it on an append-only, partitioned log for a retention period, and consumers track their own read position. That makes it better for high-throughput streaming and replay than for the complex routing and per-message acking that RabbitMQ excels at.
- What delivery guarantee does a message broker provide?
- Most brokers default to at-least-once: a message is redelivered if the consumer does not acknowledge it, so it may arrive more than once. Some support exactly-once or ordered FIFO delivery, like Amazon SQS FIFO queues. At-most-once is also possible but risks losing messages. Because duplicates can happen, consumers should be idempotent.
- When should I not use a message broker?
- Avoid one when you need a synchronous, immediate reply, such as a user query that must return data right now. A direct API or RPC call is simpler there. Also skip it for very low-volume internal calls where the operational cost of running and monitoring a broker outweighs the benefit of decoupling.
- What happens to messages if a consumer crashes?
- With acknowledgements enabled, the broker only removes a message after the consumer acks it. If the consumer crashes mid-processing, the message is never acked, so the broker requeues it for another consumer. Messages that keep failing are usually routed to a dead-letter queue after a retry limit for manual inspection.
Learn Message Broker hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
Message Queue
A buffer that stores messages between producers and consumers. Messages are processed one by one, in order. Think of it as a to-do list for your services.
Pub/Sub
A messaging pattern where publishers send messages to topics, and subscribers receive messages from topics they care about. Publishers don't know who's listening.
Kafka
A distributed event streaming platform that handles millions of events per second. Used by LinkedIn, Netflix, and Uber for real-time data pipelines.
Webhook
An HTTP callback triggered by an event. Instead of polling for updates, the source system pushes a notification to your URL when something happens.
Kafka Topic
A named feed or category to which producers publish records. Topics are split into partitions for parallelism, and each partition is an ordered, immutable log.
Kafka Partition
A subset of a Kafka topic that provides ordering guarantees and parallel processing. Each partition lives on one broker and can be consumed by one consumer per group.