Publish-Subscribe Pattern
BeginnerIn the pub-sub pattern, publishers send messages to a topic (not directly to subscribers). Subscribers express interest in topics and receive all messages published to them. This decouples producers from consumers.
Overview
Publish-subscribe (pub-sub) is a messaging pattern where senders (publishers) do not send messages directly to receivers (subscribers). Instead, messages are published to a named channel (topic). The messaging system delivers a copy of each message to every subscriber of that topic. This creates one-to-many communication — one event reaches all interested consumers. Pub-sub is fundamental to event-driven architectures, real-time notifications, and fan-out processing. Implementations include Kafka topics, AWS SNS, Google Pub/Sub, Redis Pub/Sub, and RabbitMQ fanout exchanges. Pub-sub differs from point-to-point queues: in a queue, each message is consumed by one consumer; in pub-sub, each message is delivered to all subscribers.
Pub-Sub vs Point-to-Point
In point-to-point (queue), each message goes to one consumer. In pub-sub, each message is broadcast to all subscribers. Many systems support both patterns.
// Point-to-point (queue) — one consumer processes each message
// Producer → [Queue] → Consumer A gets msg1
// → Consumer B gets msg2 (competing consumers)
// Pub-sub (topic) — all subscribers get every message
// Publisher → [Topic] → Subscriber A gets msg1
// → Subscriber B gets msg1 (both get same msg)
// → Subscriber C gets msg1
// Kafka supports BOTH:
// - Pub-sub: different consumer groups each get all messages
// - Queue: consumers in the SAME group split messages (competing)
// AWS SNS (pub-sub) + SQS (queue) combo
// SNS Topic: "order-events"
// ├→ SQS Queue: "payment-processing" (Payment service)
// ├→ SQS Queue: "inventory-updates" (Inventory service)
// └→ Lambda: "send-confirmation" (Email service)
// Each subscriber gets every message independentlyImplementation Examples
Cloud-native pub-sub services (SNS, Google Pub/Sub) handle scaling and delivery. Self-managed options (Kafka, RabbitMQ) provide more control.
// AWS SNS + SQS fan-out (Terraform)
resource "aws_sns_topic" "order_events" {
name = "order-events"
}
resource "aws_sqs_queue" "payment_queue" { name = "payment-processing" }
resource "aws_sqs_queue" "inventory_queue" { name = "inventory-updates" }
resource "aws_sns_topic_subscription" "payment" {
topic_arn = aws_sns_topic.order_events.arn
protocol = "sqs"
endpoint = aws_sqs_queue.payment_queue.arn
}
resource "aws_sns_topic_subscription" "inventory" {
topic_arn = aws_sns_topic.order_events.arn
protocol = "sqs"
endpoint = aws_sqs_queue.inventory_queue.arn
}
// Redis Pub/Sub (simple, no persistence)
// Publisher: PUBLISH order-events '{"orderId":"123"}'
// Subscriber: SUBSCRIBE order-events
// ⚠️ Redis pub-sub has no persistence — if subscriber is offline, message is lostKey Points to Remember
- 1Pub-sub is one-to-many: one message is delivered to all subscribers of a topic.
- 2Point-to-point queues are one-to-one: each message goes to exactly one consumer.
- 3Kafka supports both patterns — different consumer groups for pub-sub, same group for competing consumers.
- 4SNS + SQS fan-out is the standard AWS pattern for pub-sub with durable delivery.
- 5Redis Pub/Sub is fast but has no persistence — messages are lost if subscribers are offline.
Interview Questions
Sign in to ask AriaWhat is the publish-subscribe pattern?
How does pub-sub differ from a message queue?
How does Kafka support both pub-sub and competing consumer patterns?
Design a notification system using pub-sub to deliver push, email, and SMS.
How would you handle slow subscribers in a pub-sub system without blocking fast ones?
Ask Aria about Publish-Subscribe Pattern
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.