Message Queue vs Pub/Sub vs Event Bus, Explained

12 min read · Last updated: October 24, 2026

A message queue delivers each message to exactly one consumer, so a pool of workers shares the load. Pub/sub delivers a copy of each message to every subscriber, so many services react to one event. An event bus is a router: it matches each event against rules and sends it only to the targets those rules name.

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The patterns

• Point-to-Point Channel, Enterprise Integration Patterns
• Publish-Subscribe Channel, Enterprise Integration Patterns
• Message Bus, Enterprise Integration Patterns

The cloud docs

• Microsoft Learn: Compare Event Grid, Event Hubs and Service Bus, updated June 12, 2026
• Microsoft Learn: Service Bus queues, topics and subscriptions, updated October 6, 2026
• AWS docs: Amazon SQS visibility timeout
• AWS docs: Fanout Amazon SNS notifications to Amazon SQS queues
• AWS docs: Amazon EventBridge event bus
• Google Cloud: Pub/Sub overview, updated October 22, 2026

The brokers and the database

• Apache Kafka 4.2 introduction
• Apache Kafka 0.10.2 introduction source (the consumer group explanation)
• RabbitMQ tutorial 3: Publish/Subscribe
• PostgreSQL 18 docs: SELECT, the locking clause

Key takeaways

• A queue gives each message to exactly one consumer. Pub/sub gives every subscriber its own copy. An event bus sends an event to zero or more targets based on rules.
• "Topic", "bus" and "hub" are product names, not physics. Azure Service Bus has both queues and topics, and Kafka does both models with consumer groups.
• Amazon SQS hides a received message for 30 seconds by default and up to 12 hours. If you do not delete it in time, another worker gets it.
• On Azure: Service Bus for orders and transactions, Event Hubs for telemetry streams at millions of events per second, Event Grid for reacting to state changes.
• A Postgres table can be a small queue with SKIP LOCKED, but the PostgreSQL docs say that mode is not suitable for general purpose work.

Message queue vs pub sub vs event bus: the short answer

The difference is who gets each message. A queue hands it to one consumer, and it is gone once processed. Pub/sub copies it to every subscriber. An event bus filters it through rules and delivers it only where a rule matches. Pick by delivery promise, not by product name, because most products support more than one model.

Here is the whole comparison on one screen.

	Message queue	Pub/sub (topic)	Event bus
Who receives a message	Exactly one consumer	Every subscriber gets a copy	Every target whose rule matches
Relationship	One-to-one (point-to-point)	One-to-many (fan-out)	Many-to-many, filtered
Does the sender know the receiver?	No, it knows the queue	No, it knows the topic	No, it knows the bus
Typical payload	A command: "resize this image"	An event: "order placed"	An event with fields to route on
Adding a new consumer	Shares the existing work	Gets its own copy of everything	Add a rule and a target
Main job	Spread work, absorb spikes	Notify many services at once	Route events from many sources
Real products	Amazon SQS, Service Bus queues, RabbitMQ work queues	Amazon SNS, Google Pub/Sub, Service Bus topics, Kafka	Amazon EventBridge, Azure Event Grid

If you remember one line: a queue splits work, a topic copies news, a bus routes news.

What is a message queue?

A message queue is a buffer where producers drop messages and consumers pull them out, with each message processed by only one consumer. Microsoft's Service Bus docs describe FIFO delivery "to one or more competing consumers", where "only one message consumer receives and processes each message." It exists to spread work and smooth out spikes.

                         +--> Worker A   (takes m1)
Producer --> [ m3 m2 m1 ]--> Worker B   (takes m2)
                         +--> Worker C   (takes m3)

Each message is processed once, by one worker.

The Enterprise Integration Patterns catalog calls this a Point-to-Point Channel: it "ensures that only one receiver consumes any given message." Many workers can read from it at the same time, and the channel makes sure only one of them gets each message. The workers do not need to coordinate with each other.

How does the queue know a message is done?

This is where queues earn their keep. Amazon SQS, AWS's managed queue, does not delete a message when you receive it. The message stays in the queue but becomes invisible to other consumers for the visibility timeout, which defaults to 30 seconds. You process it, then you delete it. If your worker crashes and the timeout expires, the message becomes visible again and another worker picks it up. You can extend the timeout, but never past 12 hours from first receipt.

Azure Service Bus does the same thing and calls it peek lock. It locks the message, hands it to you, and only marks it consumed when you say you are done. Microsoft names the trade-off directly: crash after processing but before completing, and the message is redelivered. That is at-least-once processing, so your consumer has to handle duplicates.

Strengths of a queue, with evidence

Microsoft's Service Bus docs list four benefits, and they are the honest reasons anyone uses a queue:

• Temporal decoupling. Producer and consumer do not have to be online at the same time, because messages are stored durably.
• Load leveling. The consumer only needs to handle average load, not peak load. Microsoft says this saves infrastructure costs.
• Competing consumers. Add workers and each message still goes to only one of them.
• Loose coupling. You can upgrade the consumer without touching the producer.

What is publish/subscribe?

Publish/subscribe is a pattern where a publisher sends a message to a topic, and every subscriber of that topic receives its own copy. The publisher does not know who is listening. Enterprise Integration Patterns defines it as a channel that "delivers a copy of a particular event to each receiver." Add a subscriber and it starts receiving, without any change to the publisher.

                                     +--> Email service      (copy)
Publisher --> [ topic: order.placed ]--> Inventory service  (copy)
                                     +--> Analytics          (copy)

Every subscriber gets every message.

RabbitMQ, the open-source message broker, makes the mechanics visible. Its tutorial states that "the producer never sends any messages directly to a queue." Producers send to an exchange. A fanout exchange "just broadcasts all the messages it receives to all the queues it knows." Each subscriber binds its own queue to that exchange, so pub/sub in RabbitMQ is really fan-out into many queues.

AWS does the same thing with two services. You publish to an Amazon SNS topic, and SNS pushes a copy into every Amazon SQS queue subscribed to it. AWS describes the result plainly: apps that need instant notification get it, and the messages also persist in SQS "for other applications to process later."

Azure Service Bus topics work the same way. A subscription "resembles a virtual queue that receives copies of the messages that are sent to the topic." Subscriptions can also carry filters, so a subscriber receives only a subset.

Strengths of pub/sub, with evidence

• One event, many reactions. Google Cloud describes Pub/Sub as a service that "decouples services producing messages from services processing those messages."
• No waiting. Google notes that publishers do not wait for subscribers to process events, unlike synchronous remote procedure calls.
• New consumers do not touch old ones. A new subscriber gets its own copy and leaves existing subscribers alone.

What is an event bus?

An event bus is a router that receives events from many sources and delivers each one to the targets whose rules match it. AWS defines its classic event bus as "a router that receives events and delivers them to zero or more destinations, or targets." The key difference from plain pub/sub is content-based routing: you describe what you want, and the bus decides.

Sources              Event bus (rules)                    Targets
Billing app  --> | source = billing, type = paid  | --> Invoice function
Auth service --> | type = user.deleted            | --> Cleanup job, Audit log
EC2          --> | state = running                | --> Lambda function
                 | no rule matches                | --> nothing happens

In Amazon EventBridge, rules attached to the bus check each incoming event against an event pattern, a small JSON document. AWS's own example matches EC2 instances changing state to running:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["running"]
  }
}

An event can match several rules, and each rule can point at up to five targets. If no rule matches, EventBridge takes no action. AWS services also send their own events to a default event bus in every account automatically.

Strengths of an event bus, with evidence

• Many sources to many targets. AWS positions classic event buses for exactly that, with optional transformation before delivery.
• Routing lives in config, not code. The publisher sends one event; rules decide who cares.
• Zero matches is safe. An event nobody asked for simply goes nowhere.

Publish subscribe vs producer consumer: what actually differs?

In the producer/consumer model, consumers compete: one message, one consumer, and adding consumers adds throughput. In publish/subscribe, subscribers do not compete: one message, every subscriber, and adding subscribers adds copies. Both decouple sender from receiver. The real question is whether your consumers are interchangeable workers or different services.

Apache Kafka, the open-source event streaming platform, shows that this is a setting, not two different products. Kafka's introduction puts it this way: messaging "traditionally has two models: queuing and publish-subscribe." Consumers label themselves with a consumer group name, and "each record published to a topic is delivered to one consumer instance within each subscribing consumer group."

So:

• Same group for all your consumers, and records are load balanced across them. That is a queue.
• Different groups, and every group gets every record. That is pub/sub.

Kafka's docs say "the consumer group concept in Kafka generalizes these two concepts." Kafka also differs from a classic queue in one way that matters: "unlike traditional messaging systems, events are not deleted after consumption." Retention is set per topic, and order is guaranteed only within a partition, not across the whole topic.

Message queue vs message bus

A message queue is one channel with one job: hold messages until a consumer takes them. A message bus is an architecture built from messaging, where many applications share a common data model, a common command set and a messaging infrastructure. A queue is a part. A bus is a whole agreement between systems.

That three-part definition comes from the Enterprise Integration Patterns catalog. It compares a message bus to a computer's hardware bus that connects the CPU, memory and peripherals. Underneath, the bus can be built from queues, publish-subscribe channels and routers.

In practice the words blur because products borrow them. "Azure Service Bus" is a product with both queues and topics. "Event bus" at AWS means a rule-based router. When someone says "bus", ask which of the three delivery promises they mean.

Service bus vs event hub vs event grid: which Azure service?

Use Service Bus for high-value business messages like orders and payments. Use Event Hubs for high-volume streams like telemetry. Use Event Grid to react to state changes, such as an item being shipped. Microsoft's own comparison, updated June 12, 2026, frames the three as transactional messaging, data streaming and reactive event routing.

Microsoft draws a line between events and messages first. An event is "a lightweight notification of a condition or state change" and "the publisher has no expectation about how the event is handled." A message carries raw data, and "a contract exists between publisher and consumer."

	Azure Service Bus	Azure Event Hubs	Azure Event Grid
Primary purpose	Enterprise transactional messaging	Big data streaming and ingestion	Reactive event routing
Data model	Messages (high-value payloads)	Event streams (time-ordered series)	Events (discrete notifications)
Throughput	Reliable asynchronous delivery	Millions of events per second	Dynamically scalable, serverless
Ordering	FIFO with sessions	Per partition	No guarantee
Transactions	Yes	No	No
Duplicate detection	Yes	No	No
Dead-lettering	Yes	No	Yes
Replay	No	Yes (Event Hubs Capture)	No
Protocols	AMQP, HTTP	AMQP, Kafka, HTTP	MQTT, HTTP
Use it for	Order processing, financial transactions, workflows	Telemetry, real-time analytics	Status changes, serverless apps

All three deliver at least once. Microsoft's example uses all three in one e-commerce site: Service Bus to process orders, Event Hubs to capture site telemetry, and Event Grid to respond to an item being shipped.

Message queue vs web service: when is a direct API call better?

Call a web service when you need an answer right now, like checking a password or loading a page. Use a queue when the caller does not need the result immediately, like sending an email or generating a report. A direct call needs both sides online at once. A queue does not, which is what Microsoft calls temporal decoupling.

Think of a signup flow. The API that creates the account should answer the user directly. The welcome email, the analytics event and the CRM sync can go onto a queue or topic. If the email provider is down for a while, the messages wait, and the user never notices.

The cost is that you lose the immediate response. If the caller needs the result to continue, keep it synchronous. I wrote about keeping internal APIs simple in why your private API does not need HTTP status codes.

Why use a message broker instead of a database?

You can use a database as a small queue, and at low volume it works. A broker gives you the delivery machinery out of the box: locks with timeouts, redelivery after crashes, dead-letter queues, fan-out to many subscribers and push delivery. In a database you build and maintain each of those yourself, on a table designed for queries, not handoffs.

PostgreSQL even documents the pattern. With FOR UPDATE SKIP LOCKED, rows that another worker has locked are skipped instead of waited on:

BEGIN;

SELECT id, payload
FROM jobs
WHERE status = 'pending'
ORDER BY id
LIMIT 1
FOR UPDATE SKIP LOCKED;

-- do the work in your app, then:
UPDATE jobs SET status = 'done' WHERE id = $1;

COMMIT;

The PostgreSQL 18 docs add the warning in the same breath: skipping locked rows "provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table."

Compare what you get from a managed queue:

Need	Postgres table	Managed broker (SQS, Service Bus)
One worker per job	SKIP LOCKED	Built in (visibility timeout, peek lock)
Retry after a crash	You write it (status plus timestamp)	Built in, the message reappears
Poison messages	You write it	Dead-letter queue
Fan-out to many services	You write it	Topics and subscriptions
Same transaction as your data	Yes	No

That last row is the real argument for the database. If the job must be created in the same transaction as the order row, a table is simpler. Once you need retries, dead-lettering or fan-out, use the broker.

Do I need a message queue?

You need a queue when work can happen later, when traffic spikes past what your workers can handle at once, or when a slow downstream service should not slow down your users. You do not need one when every caller needs an immediate answer, or when volume is low enough that a database table already does the job.

Run your feature through these questions:

1. Does the user need the result in this request? If yes, call the service directly.
2. Can the work fail and retry without the user noticing? If yes, a queue fits.
3. Does more than one service care about this event? If yes, you want pub/sub, not a queue.
4. Do events come from many sources and need routing by content? If yes, look at an event bus.
5. Do you need to replay history or feed analytics? If yes, look at a log-based stream like Kafka or Event Hubs.
6. Is volume low, with one worker and no fan-out? A database table is fine. Revisit when that changes.

Which should you pick? Message queue vs pub/sub vs event bus by situation

Pick a queue when the work is a command for one worker. Pick pub/sub when several services need the same event. Pick an event bus when events from many sources need routing by content, and a stream when you need replay. When the job must commit together with your data, a database table wins.

Your situation	Pick	Example product
Background jobs: emails, image resizing, PDF reports	Message queue	Amazon SQS, Service Bus queue, RabbitMQ work queue
Absorbing traffic spikes so workers handle average load	Message queue	Amazon SQS, Service Bus queue
One event, several services must react	Pub/sub	Amazon SNS to SQS, Google Pub/Sub, Service Bus topic
Payments and orders needing ordering, duplicate detection, transactions	Queue with sessions	Azure Service Bus
React to cloud or SaaS events, route by content	Event bus	Amazon EventBridge, Azure Event Grid
High-volume telemetry with replay	Event stream	Apache Kafka, Azure Event Hubs
Job must be created in the same transaction as your data	Database table	PostgreSQL with SKIP LOCKED

What are real-world uses of message queues?

Real systems use queues and topics for work that should not block a user: sending email alerts, formatting images, collecting user activity, streaming database changes and refreshing caches. Google Cloud's Pub/Sub docs list these patterns directly, and Microsoft's e-commerce example splits orders, telemetry and shipping events across three different services.

From Google Cloud's list of common uses, in docs updated October 22, 2026:

• Ingesting user activity and server events from many clients and routing them to storage like BigQuery.
• Distributing work such as file compression, email alerts, AI model evaluation and image formatting across workers.
• Streaming database change events to build current and historical views of data.
• Sending invalidation events to refresh distributed caches.
• Streaming data from SaaS apps and IoT sensors into data pipelines.

This exact question shows up in system design rounds, and the strong answers name the delivery promise before the product. If that round worries you, read why most developers fail system design interviews.

FAQ

Is Kafka a message queue or pub/sub?

Both, depending on consumer groups. Kafka's docs explain that consumers in the same group split the records between them like a queue, while separate groups each receive every record like pub/sub. Unlike a classic queue, Kafka keeps events after they are read, for as long as the topic's retention setting allows.

Is a topic the same as a queue?

No. A queue gives each message to one consumer. A topic gives each message to every subscription. In Azure Service Bus, each topic subscription behaves like its own virtual queue, so you can still run competing consumers on a single subscription.

What happens if a consumer crashes mid-message?

In Amazon SQS, the message becomes visible again after the visibility timeout, 30 seconds by default, and another consumer can take it. In Azure Service Bus peek lock mode, the lock expires and the message is redelivered. Both are at-least-once, so make your handlers safe to run twice.

Is an event bus just pub/sub with a new name?

Close, with one real difference. In pub/sub, a subscriber usually gets everything on the topic unless it adds a filter. An event bus like Amazon EventBridge evaluates every event against rules and sends it only to matching targets, up to five per rule, and does nothing when no rule matches.

Pick one slow, non-urgent call in your app this week and move it behind a queue. While you build, the free tools on Art of Code handle the small chores, and if you want the interview angle, start with why most developers fail system design interviews.

Written by Adithya Guttha, Founder of Art of Code.