Message Broker
What Is a Message Broker?
A message broker is software that receives messages from one application and delivers them to the right service or services. It enables asynchronous communication, so the sender does not need to wait for the receiver, unlike a direct API call.
How a Message Broker Works
A broker sits between message producers and consumers.
- A producer creates a message, such as “order created.”
- It sends the message to a queue for one worker or a topic for many subscribers.
- The broker applies routing rules and stores the message if needed.
- A consumer receives and processes the message.
- The consumer sends an acknowledgement. Failed messages can be retried or moved to a dead-letter queue for review.
Message Queue vs Pub-Sub vs Event Streaming
These patterns solve different delivery and retention needs.
| Pattern | Audience | Retention | Example |
|---|---|---|---|
| Work queue | One worker | Until processed | Image processing |
| Publish-subscribe | Many subscribers | Usually short-term | Notifications |
| Event streaming | Many readers | Configured retention | Analytics pipeline |
Kafka uses brokers and can handle queue-like workloads, but it is primarily designed for retained event streams that consumers can replay.
A Simple Message Broker Example
At checkout, an app publishes an order-created event. Inventory reserves stock, payment charges the customer, notifications send a receipt, and analytics records the sale independently. Consumers should be idempotent, meaning a retry does not charge a card or reduce stock twice.
Benefits of Using a Message Broker
Brokers are especially useful in microservices and event-driven systems.
- They decouple services and reduce direct dependencies.
- They absorb traffic spikes and support parallel processing.
- They isolate temporary failures through durable retries.
- They let one event fan out to multiple consumers.
Practical Limits and Risks
A broker adds important operational responsibilities.
- Data may be eventually consistent rather than immediately updated everywhere.
- Duplicates and ordering limits require careful consumer design.
- Teams must monitor queues, failures, schemas, access controls, and costs.
- A simple request-and-response workflow may be clearer with a direct API call.
When to Use a Message Broker
Choose a broker when work can happen independently or later.
- Run background jobs or long-running tasks.
- Buffer unreliable third-party integrations.
- Scale services separately, send notifications, or build data pipelines.
- Prefer direct API calls when a user needs an immediate answer from one service.
Common Message Broker Technologies
Selection depends on routing, retention, delivery guarantees, and who operates the infrastructure.
| Technology | Best fit |
|---|---|
| RabbitMQ | Flexible routing and reliable task queues |
| Apache Kafka | High-volume, replayable event streams |
| Amazon SQS and SNS | Managed queues and pub-sub on AWS |
| Google Pub/Sub | Managed event delivery on Google Cloud |
| ActiveMQ | Enterprise messaging and Java ecosystems |
Building Event-Driven Applications with Emergent
When building a full-stack product, describe the events, consumers, retry rules, and integrations alongside the user flow. Emergent can help teams create an AI app builder project, connect workflow logic with its AI automation builder, and ship an event-aware AI web app builder experience.
on Emergent today

