Side by side
| Dimension | Pub/sub | Message queue |
|---|---|---|
| Primary purpose | Distribute events to independent consumers | Distribute jobs across competing workers |
| Who receives a message | Each matching subscription | One worker per delivery attempt |
| Scaling consumers | New subscriptions add independent processing | More workers share the existing backlog |
| Consumer progress | Tracked separately per durable subscription | Shared queue tracks pending and in-flight work |
| Offline consumers | Need durable subscriptions or retained events | Durable queues hold jobs until processed or expired |
| Retries and duplicates | Depend on subscription delivery policy | Often use acknowledgments and visibility leases |
| Ordering | Often scoped to a key or partition | Parallel workers and retries can reorder completion |
| Typical use | Order events to billing, analytics, and notifications | Transcoding, email sending, and background jobs |
The differences that matter
The key distinction is independent processing versus shared work. If billing and analytics both need every OrderCreated event, give them separate subscriptions. If ten email workers should divide email jobs, put them behind one queue or one shared subscription. Putting billing and analytics on a single competing-consumer queue would cause each to miss work it needs.
Pub/sub does not inherently mean ephemeral delivery, and a queue does not inherently guarantee durability. Specify whether messages survive broker failures, whether disconnected subscribers retain a backlog, and when retention expires. Replay of already processed events requires retained history or another source of truth, not merely durable delivery.
Failure handling must be scoped correctly. Independent durable subscriptions let analytics fall behind without advancing billing's progress, although shared broker resources can still cause interference. Define retry limits, dead-letter handling, and backlog quotas for each subscription or queue. At-least-once delivery in either pattern requires idempotent processing.
Scaling changes ordering and capacity requirements. More workers can increase job throughput, but strict ordering for one key limits parallelism. Pub/sub also multiplies downstream processing: three subscriptions that each receive every event create roughly three times the logical deliveries, before retries. Plan capacity and backpressure per consumer, not just at the publisher.
Choose Pub/sub when
- Several services each need the same business event and must track processing independently.
- You expect to add consumers without changing the producer or disrupting existing consumers.
- Consumers need different retry policies, backlog limits, or processing speeds.
- You need live broadcast to connected subscribers, and have explicitly decided whether missed updates require durable recovery.
Choose Message queue when
- Each job needs one successful processing outcome, with workers sharing the backlog.
- You need to absorb bursts of expensive work such as image resizing or video transcoding.
- You need explicit job acknowledgments, processing leases, bounded retries, and poison-message handling.
- Your main scaling requirement is adding workers to an existing task pipeline, not adding independent event consumers.
A worked example
Order events with independent worker pools
Suppose a store produces 1,000 OrderCreated events per second. Billing, notifications, and analytics each need every event, so publish to three durable subscriptions, creating 3,000 logical deliveries per second before retries. Notification instances share one subscription rather than creating a subscription per instance. If each notification job occupies a worker slot for 100 milliseconds, that stage needs roughly 100 concurrent slots just to match arrivals, plus headroom. If analytics stops for ten minutes, its subscription accumulates 600,000 events while the others continue, provided retention and broker capacity allow it. Use idempotency keys because retries can repeat processing.
In the interview
- Start with: does every consumer role need this message, or should any available worker handle it? Draw logical subscriptions separately from worker instances.
- State delivery guarantees separately from topology. Explain what happens if a worker performs a side effect and crashes before acknowledging the message.
- Define ordering scope, such as per order or per account. Expect questions about partition keys, hot keys, retries, and the throughput cost of serialized processing.
- Estimate arrival rate, processing time, fan-out, and tolerable backlog age. Explain how you detect lag and what happens when a consumer cannot catch up.
- For events derived from database writes, explain how an outbox avoids losing an event between committing the transaction and publishing it.
Common mistakes
- Saying pub/sub sends every message to every process. Delivery is usually defined per matching subscription; worker instances may share one subscription.
- Assuming a queue prevents duplicate execution or guarantees exactly-once external side effects.
- Treating pub/sub as always transient or queues as automatically durable, ordered, and replayable.
- Choosing a broker product before defining fan-out, acknowledgment behavior, retention, and consumer isolation.
Where it comes up
Interview questions where choosing between Pub/sub and Message queue comes up.
- Design a notification systemFan out business events to independent channels, then distribute delivery jobs across workers with channel-specific retries.
- Design a distributed message queue like RabbitMQThe design centers on competing consumers, visibility leases, acknowledgments, and duplicate delivery.
- Design a distributed message log like KafkaIndependent consumer progress and retained history explain how a log supports both fan-out and shared processing.
- Design a video streaming service like YouTubeUpload events can trigger independent workflows while worker queues distribute expensive transcoding tasks.
- Design a chat app like WhatsAppLive message fan-out and durable offline delivery require different subscription and retention decisions.
- Design a distributed job schedulerScheduled occurrences become durable jobs that workers claim and retry without duplicating side effects.
Questions people ask
What is the difference between pub/sub and a message queue?
Pub/sub gives each matching subscription access to an event, allowing independent consumers to process it. A message queue distributes work among competing workers. Both can support durable storage, acknowledgments, and retries, depending on the system and configuration.
Can pub/sub be used as a message queue?
Yes. A durable subscription shared by multiple workers can provide queue-like work distribution. Separate subscriptions provide fan-out, while workers within each subscription divide the work.
Is Kafka pub/sub or a message queue?
Kafka supports both patterns through consumer groups over a retained partitioned log. Separate groups independently read the same records, while consumers within a group share partition assignments. Its offset and retention model differs from a traditional queue that removes acknowledged messages.