Homeglossary

Message Broker

A message broker is a software intermediary that receives messages from one application and delivers them to the right service or services. It enables asynchronous communication, so a sender and receiver do not need to be available at the same time. Brokers can queue, route, transform, persist, and retry messages according to defined rules.

Build event-driven apps with Emergent.

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.

  1. A producer creates a message, such as “order created.”
  2. It sends the message to a queue for one worker or a topic for many subscribers.
  3. The broker applies routing rules and stores the message if needed.
  4. A consumer receives and processes the message.
  5. 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.

PatternAudienceRetentionExample
Work queueOne workerUntil processedImage processing
Publish-subscribeMany subscribersUsually short-termNotifications
Event streamingMany readersConfigured retentionAnalytics 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.

TechnologyBest fit
RabbitMQFlexible routing and reliable task queues
Apache KafkaHigh-volume, replayable event streams
Amazon SQS and SNSManaged queues and pub-sub on AWS
Google Pub/SubManaged event delivery on Google Cloud
ActiveMQEnterprise 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.

Start Building
on Emergent today
Start Building