Pub/Sub vs Message Queues
Message queues deliver each message to exactly one consumer for task distribution, while pub/sub broadcasts each message to all subscribers for event notification — and most real systems use both patterns in different parts of their architecture.
A message queue (point-to-point) is a work distribution system: a message is consumed by exactly one worker from a pool. Think of it as a task list — once a worker picks up a task, no other worker processes it. SQS, RabbitMQ's default mode, and Sidekiq work this way.
Pub/sub (publish-subscribe) is a broadcast system: a message published to a topic is delivered to every subscriber. Think of it as a radio station — everyone tuned in hears the same broadcast. SNS, Redis Pub/Sub, and Google Pub/Sub work this way.
Kafka blurs the line: it's a distributed log where consumer groups provide queue semantics (each message processed by one consumer per group) while multiple groups can independently consume the same topic (pub/sub semantics). This is why Kafka dominates modern event-driven architectures.
Tradeoffs
Message Queues — Strengths
- Simple mental model: one message, one consumer
- Natural backpressure via queue depth
- Easy to scale: add more workers
- Straightforward exactly-once semantics with idempotency
- Simpler security model (fewer endpoints to secure)
Message Queues — Weaknesses
- Can't broadcast to multiple consumers (need separate queues)
- Message is deleted after consumption — no replay capability
- Tight coupling if multiple services need the same event (each needs its own queue)
Pub/Sub — Strengths
- Decouples producers from consumers completely
- Adding a new subscriber requires zero changes to the publisher
- Enables event-driven architecture and event sourcing
- Kafka's log retention enables replay for debugging and reprocessing
Pub/Sub — Weaknesses
- Harder to reason about delivery guarantees across multiple subscribers
- Ordering is more complex (partition-level, not global)
- Larger attack surface — more subscribers means more endpoints to secure and audit
- Debugging is harder: who consumed what, when?
The Hybrid: SNS + SQS (AWS)
AWS's recommended pattern is SNS (pub/sub) fanning out to SQS queues (one per subscriber). Each subscriber gets queue semantics (retry, DLQ, backpressure) with pub/sub flexibility. This is the most common pattern at AWS-native companies.
Likely Follow-Up Questions
- How would you handle a subscriber that falls behind in a pub/sub system?
- When would you use SNS+SQS (fan-out to queues) instead of Kafka?
- How do you ensure exactly-once processing in a queue-based system?
- What happens to undelivered messages when a pub/sub subscriber is offline?
- How would you partition a Kafka topic for an e-commerce order system?
- What are the security implications of fan-out — how do you prevent unauthorized subscribers?
Related Concepts
Source: editorial — Synthesized from production architectures at Uber, Shopify, Netflix, Stripe, and AWS documentation