Pub/Sub vs Message Queue

You already know a message queue lets one service hand off work to another without waiting around. But when you start building real systems, you hit a fork in the road:

• Sometimes you want one message to be handled by exactly one worker. Like “process this payment” should run once, not three times.
• Other times you want one message to reach many services at once. Like “an order was placed” should tell the email service, the inventory service, and the analytics service, all of them.

These are two different shapes of messaging. The first is a plain message queue. The second is pub/sub. Knowing which is which saves you from nasty bugs, so let’s break it down.

🎯 Message Queue: One Message, One Worker

In a plain message queue, messages line up and each message is handled by just one consumer. Even if you have several workers reading from the queue, any single message goes to only one of them.

Think of a single line at a bank with several tellers:

• Customers (messages) wait in one line.
• Several tellers (workers) pull the next customer when they’re free.
• Each customer is served by exactly one teller. Nobody gets served twice.

So a queue is about sharing out work. Add more workers and the line moves faster, but each task still runs once. This is perfect for jobs that must happen exactly one time, like charging a payment or sending one confirmation email.

📢 Pub/Sub: One Message, Many Subscribers

Pub/sub stands for publish/subscribe. Here the idea flips. A message (called an event) is delivered to every subscriber that’s interested. One message, many receivers.

The two roles:

• A publisher sends out a message about something that happened, like “order #55 was placed.” It doesn’t know or care who’s listening.
• Subscribers are services that signed up to hear about those messages. Each one gets its own copy.

Back to the order example. When an order is placed, the publisher sends one “order placed” event, and every subscriber gets it:

• The email service gets it and sends a confirmation.
• The inventory service gets it and lowers the stock count.
• The analytics service gets it and updates the dashboard.

One event, three services, all notified. That’s broadcasting, and it’s what pub/sub is built for.

🔍 The Core Difference

Let me make the difference sharp, because it’s the whole lesson:

• A queue shares work out. Each message is handled once, by one worker. Good for tasks.
• Pub/sub broadcasts. Each message reaches every subscriber. Good for notifying many services about an event.

🧭 When to Use Which

A simple way to decide:

• The task should run exactly once, like charging a card or resizing one image? Use a queue.
• The event should reach many services, each doing its own thing? Use pub/sub.

Often a real system uses both. The “order placed” event goes out by pub/sub to several services, and inside one of those services, the actual work (like “send this one email”) sits on a queue handled by one worker.

⚠️ Common Mistakes and Misconceptions

A few things to keep straight:

• “A queue with many workers means every worker runs the message.” No. Many workers just share the load. Each message still runs once, on one worker.
• “Pub/sub guarantees only one service acts.” The opposite. Pub/sub sends a copy to every subscriber on purpose. If you need a task to run once, that’s a queue.
• “Pub/sub means the publisher picks who gets it.” No. The publisher just announces the event. Subscribers choose what to listen to. The sender doesn’t know who’s out there.

🧩 What You’ve Learned

Nice work. Here’s the recap:

• ✅ A message queue delivers each message to one worker, to share out work that should run once.
• ✅ Pub/sub delivers each message to every subscriber, to broadcast an event to many services.
• ✅ Adding workers to a queue speeds it up; it does not make a message run more than once.
• ✅ Use a queue for run-once tasks, pub/sub for “tell everyone” events; real systems often use both.

🧠

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

1. 1

   In a plain message queue, each message is handled by how many workers?

   Every worker Exactly one worker At least two None
   Check

   Why: A queue shares out work, so each message goes to just one worker, even if many workers are reading.

2. 2

   In pub/sub, a published message is delivered to whom?

   One subscriber Every interested subscriber Only the publisher A random service
   Check

   Why: Pub/sub broadcasts: every subscriber gets its own copy of the event.

3. 3

   Does adding more workers to a queue make each message run multiple times?

   Yes No, it just processes the line faster Only with Kafka Only on errors
   Check

   Why: More workers share the load so messages clear faster, but each message still runs exactly once.

4. 4

   Which fits telling the email, inventory, and analytics services that an order was placed?

   A message queue Pub/sub A database A cache
   Check

   Why: One event needs to reach many services at once, which is exactly what pub/sub is built for.

Score: 0 / 4 Reset

🚀 What’s Next?

You know the two shapes of messaging. Now let’s talk about reliability.

• Delivery Guarantees covers what happens if a message might arrive more than once, or not at all.
• Apache Kafka Introduction shows a tool that handles pub/sub at huge scale.

Get these down and you’ll know not just how messages travel, but how to trust them.