Stop 15 · Message Queues & Event-Driven ArchitectureTopics · 5/8

Pub/Sub vs Queue

In short

"Should this be a queue or pub/sub?" comes up in every system design round. The answer hangs on one question: should one worker get it, or everyone?

Pub/sub broadcasts a message to all current subscribers and loses it if no one's listening; a queue holds a message until exactly one consumer processes it — different guarantees for different needs.

The blob holds a megaphone up to a crowd with one hand and hands one parcel to one person with the other.

Think of it like this

Megaphone vs handing over a parcel

At the hostel, the warden's megaphone announcement reaches every student at once. A parcel at the gate is handed to exactly one person. Pub/sub is the megaphone: every listener hears it. A queue is the parcel: one worker takes it, and it's gone.

Watch it happen

Who gets the message?

Queue

Each message goes to one worker
Workers share the load
Good for jobs: emails, resizing images

Pub/Sub

Each message goes to every subscriber
Services react independently
Good for events: order placed, user signed up

Often you combine them: publish an event once, and give each interested service its own queue, so it gets a copy and can still spread work across its workers.

The big ideas

What you need to know

Queues split work

Ten workers on one queue means ten times the throughput. Each job is done once, by whoever is free.

Pub/sub spreads news

The publisher doesn't know who's listening. Adding a new subscriber needs no change to the publisher.

Fan-out to queues

RabbitMQ fanout exchanges, SNS to SQS and Kafka consumer groups all mix both: every service gets a copy, workers share it.

Check durability

Some pub/sub tools drop messages for offline subscribers. Queues usually keep them until a worker acks.

See it in code

Walk through the code

1// Queue: each job goes to ONE of the workers2await emailQueue.add("send", { to: "riya@example.com" });3// worker A or worker B handles it, never both4 5// Pub/Sub: each message goes to EVERY subscriber6await redis.publish("order.placed", JSON.stringify({ id: 42 }));7// email, analytics and inventory all get their own copy

1/2A job: it should happen exactly once, so one worker takes it from the queue.

Same-looking one-liners, very different behaviour. Choose by asking whether the message is a job to do or news to share.

Save yourself the pain

Common mistakes

Oops

Running three email workers as pub/sub subscribers.

Do this instead

Each would send the same email, so the customer gets three. Workers doing the same job should share a queue.

Oops

Making the order service call email, analytics and inventory directly.

Do this instead

Publish one order.placed event. Each service subscribes, and the order service stays simple.

Your mission

Sort ten real scenarios

~15 min

Quick check

You run 3 replicas of an image-resizer. Each uploaded photo should be resized once. What should they read from?

Go deeper

1Identify which pattern fits a real scenario: broadcasting a live update vs processing a background job.
2Learn that a 'topic' in Kafka behaves more like a durable, replayable pub/sub than a simple queue.
3Understand why queues suit 'do this work exactly once' and pub/sub suits 'notify everyone currently listening'.