📡

Publish-Subscribe

Asynchronous Communication via Message Broker

In the Pub/Sub pattern, publishers and subscribers do not know each other directly. A message broker (middle layer) manages messages and distributes them based on topics.

Architecture Diagram

📝
Publisher
Message Publisher
① Publish →
📡
Message Broker
Topic management + message distribution
Topic A Topic B
② Distribute →
📥
Subscriber A
📥
Subscriber B
📥
Subscriber C
Flow Description
  1. Subscribers register topics of interest with the broker (subscribe)
  2. Publisher publishes a message to a specific topic
  3. Broker distributes message to all subscribers of that topic
  4. Each subscriber processes the message independently

How It Works

1

Subscriber subscribes to a specific topic on the message broker

2

Publisher publishes a message to a specific topic

3

Message broker distributes the message to all subscribers of that topic

4

Each subscriber processes the message independently

Pros

  • ✓ Loose coupling between publishers and subscribers
  • ✓ Excellent scalability
  • ✓ Asynchronous processing possible
  • ✓ Simultaneous delivery to multiple subscribers

Cons

  • ✗ Dependency on message broker
  • ✗ Complex message ordering guarantees
  • ✗ Difficult to debug
  • ✗ Possibility of message loss

Use Cases

Redis Pub/Sub Apache Kafka AWS SNS/SQS Google Cloud Pub/Sub RabbitMQ
← 🪝 Webhook 📬 Message Queue →