What Is a Message Broker?

A message broker is an intermediary program that lets applications, services, and systems exchange information by receiving messages from senders and routing them to the correct receivers. Instead of calling each other directly, services hand their messages to the broker, which handles delivery, buffering, and routing. This decouples the parts of a system so they can run, scale, and fail independently.

Message brokers are a foundational building block of distributed systems, microservices, and event-driven architectures. They make communication asynchronous: a sender can publish a message and move on without waiting for the receiver to be online or ready. The broker holds the message until a consumer is able to process it.

How a Message Broker Works

At its core, a message broker sits between producers (the services that send messages) and consumers (the services that receive them). The flow is straightforward:

A producer creates a message — a self-contained packet of data, often with a payload plus metadata such as headers, a timestamp, or a priority.
The producer sends the message to the broker, targeting a named destination such as a queue or a topic.
The broker stores the message and manages its delivery, tracking which consumers have received it and whether they confirmed processing.
A consumer retrieves the message, does its work, and sends an acknowledgment so the broker knows the message was handled and can remove it.

The acknowledgment step is what separates a real broker from a simple fire-and-forget channel. If a consumer crashes before acknowledging, a well-designed broker makes the message available again so it is not lost. Many brokers add features on top of this loop — retries, delivery limits, dead-letter destinations, message ordering, and delayed delivery — to give developers fine-grained control over reliability.

Message Broker Messaging Patterns

Most brokers support one or both of the two core messaging patterns.

Point-to-point (queues). A message is placed on a queue and delivered to exactly one consumer. When several consumers read from the same queue, they act as competing workers and the broker load-balances messages across them. This pattern is ideal for task distribution and background job processing, where each unit of work should be done once.

Publish/subscribe (topics). A message is published to a topic, and every interested subscriber receives its own copy. This one-to-many, fan-out model suits event broadcasting — for example, notifying billing, analytics, and email services that an order was placed. You can read more about this pattern in our overview of publish/subscribe.

Message Broker vs. Message Queue

These terms are often used interchangeably, but they describe different things.

A message queue is a data structure — an ordered buffer that holds messages until a consumer retrieves them, usually in first-in, first-out (FIFO) order. It is one delivery model.

A message broker is the broader system that manages messaging between applications. A broker typically uses queues, but it does much more: it supports multiple patterns (both point-to-point and publish/subscribe), routes and transforms messages, enforces delivery guarantees, and manages acknowledgments, retries, and dead-letter handling.

In short: every message broker relies on queues or topics internally, but not every message queue is a full broker. A standalone queue moves messages between two endpoints; a broker orchestrates messaging across an entire distributed system. When you only need a lightweight buffer between a producer and a worker, a plain queue may be enough. When you need routing, multiple consumers, durability, and delivery guarantees across many services, you need a broker.

Benefits of Using a Message Broker

Decoupling. Producers and consumers do not need to know about each other or run at the same time. You can change, redeploy, or scale one side without touching the other.
Asynchronous processing. Senders are not blocked waiting for a response, which keeps applications responsive under load.
Scalability. Adding more consumers to a queue spreads work across workers automatically, letting throughput grow horizontally.
Load leveling and backpressure. The broker absorbs traffic spikes, buffering messages so downstream services are not overwhelmed.
Reliability. Persistence, acknowledgments, retries, and dead-letter destinations ensure messages survive crashes and are not silently lost.

Common Message Broker Use Cases

Message brokers show up wherever systems need to communicate reliably without tight coupling:

Microservices communication — services coordinate through messages instead of brittle direct calls.
Event-driven architectures — state changes are published as events that any number of services can react to.
Background jobs and task queues — offloading slow work such as sending email, generating reports, or processing images.
Order and transaction processing — durably capturing each step of a workflow so nothing is dropped.
Notifications and real-time updates — fanning out chat messages, alerts, or live feeds to many subscribers.
Log and stream ingestion — collecting high-volume event data for downstream processing.

Popular Message Brokers

Several widely used brokers and messaging platforms each take a different approach:

RabbitMQ — a mature broker built around flexible exchange-and-binding routing.
Apache Kafka — a distributed, log-based event-streaming platform built for very high throughput and replay.
Amazon SQS — a fully managed cloud queue service within the AWS ecosystem.
Google Cloud Pub/Sub — a global-scale managed messaging service on GCP.
Apache Pulsar — a distributed messaging and streaming platform with multi-tenancy and tiered storage.
Apache ActiveMQ / Amazon MQ — traditional JMS-oriented brokers common in Java enterprise systems.

The right choice depends on your latency needs, durability requirements, operational appetite, and whether you want to run and manage a separate broker cluster at all.

Using Redis and Valkey as a Message Broker

Because Redis and Valkey are extremely fast in-memory data stores, developers often use them for messaging to avoid deploying a separate broker. Out of the box they offer a few mechanisms:

Native pub/sub — a lightweight publish/subscribe system that broadcasts messages to currently connected subscribers. It is fast, but it is fire-and-forget: if a subscriber is offline when a message is published, that message is gone. There is no persistence and no acknowledgment.
Streams — a durable, append-only log with consumer groups and acknowledgments, so messages survive restarts and unprocessed messages can be reclaimed if a consumer stalls. Streams are capable, but higher-level reliability features — configurable delivery limits, dead-letter destinations, message priority, and delayed delivery — are not built in and have to be implemented in your own application code.
Lists — simple structures often used to build basic queues with commands like LPUSH and BRPOP, but with no acknowledgments or delivery guarantees on their own.

For simple, loss-tolerant messaging these are enough. But for mission-critical workloads — where every message matters and consumers can crash mid-processing — the native primitives leave gaps that your application code has to fill.

Reliable Messaging With Redisson PRO

Redisson is a Java client for Redis and Valkey that closes those gaps, turning the data store you already run into a durable message broker — without deploying or managing a separate broker cluster. Its messaging features cover both core patterns:

Reliable Queue brings point-to-point messaging with message acknowledgments, per-message visibility timeouts, configurable delivery limits, dead-letter queues, time-to-live, message priority (0–9), delayed delivery, deduplication, and both parallel and strictly sequential processing modes.
Reliable Pub/Sub brings durable publish/subscribe through a clear topic → subscription → consumer model, with configurable retention modes, message replay by position, ID, or timestamp, automatic redelivery, and dead-letter topics. See the complete guide to Reliable PubSub for a full walkthrough.
JMS API implementation (JMS 2.0, 3.0, and 3.1) lets Java teams use a standards-based broker with JmsTemplate, @JmsListener, Spring integration, and JNDI lookups.

Redisson PRO also adds per-operation synchronous replication, so you can force individual messages to be confirmed on replicas (and optionally an append-only file) before an operation returns — a level of durability control the native pub/sub model does not provide. The result is broker-grade reliability, ordering, and delivery guarantees running entirely on your existing Redis or Valkey infrastructure.

To see how this approach compares to dedicated brokers, read our feature comparisons against Apache Kafka, RabbitMQ, Amazon SQS, and Google Cloud Pub/Sub.

Frequently Asked Questions

Is Redis a message broker?

Redis (and Valkey) can act as a message broker through its native publish/subscribe feature and data structures like Streams. However, native Redis pub/sub is fire-and-forget, with no persistence or acknowledgments. To use Redis as a reliable broker with delivery guarantees, developers typically add a client such as Redisson PRO, which provides Reliable Queue and Reliable Pub/Sub on top of Redis or Valkey.

What is the difference between a message broker and a message queue?

A message queue is a single data structure that buffers messages in order until a consumer reads them. A message broker is the larger system that manages messaging between applications — it uses queues and topics internally but adds routing, multiple messaging patterns, delivery guarantees, acknowledgments, and dead-letter handling.

What is the difference between a message broker and a message bus?

A message broker is a central hub that receives and routes messages between services in a hub-and-spoke model. A message bus is a shared communication layer where services connect through a common interface and more of the routing logic lives at the endpoints; the enterprise service bus (ESB) is a well-known implementation of this idea. In short, brokers tend to centralize routing, while buses distribute it.

Do I need a message broker for microservices?

Not always, but a broker is common in microservices because it lets services communicate asynchronously and stay decoupled. If your services only ever make simple synchronous requests, direct API calls may suffice. Once you need buffering, retries, event broadcasting, or resilience to downstream outages, a broker becomes valuable.

Is Kafka a message broker?

Kafka is often described as a message broker, but it is more precisely a distributed event-streaming platform. It stores messages in a durable, replayable log rather than deleting them after delivery, which makes it well suited to high-throughput streaming and event sourcing, and different from traditional queue-based brokers.