We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Messaging & Event Systems
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Message Broker across a run of lessons, not one page. These 4 alone are about 76 minutes of step-by-step reading, every one with a quiz.
Decouple producers from consumers with a buffer that holds messages until they're processed.
Never lose a message, but you might see it twice.
Guaranteeing messages arrive in the right sequence, harder than it sounds.
Design consumers that produce the same result whether a message is processed once or ten times.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Message Queuespay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This page explains the idea. The "Message Queues" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Message Queues lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Message Broker in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
