Pub/Sub Architecture

Explain Like I’m Five

Imagine you’re a newspaper publisher 📰. Every day, you print news about different topics: sports, weather, politics, and entertainment.

Instead of delivering papers only to people you know, you set up a newsstand (like a message broker) where anyone can subscribe to the topics they care about.

• Sports fans subscribe to “Sports” → they get sports news.
• Weather watchers subscribe to “Weather” → they get weather updates.
• Politics nerds subscribe to “Politics” → they get political news

You (the publisher) don’t know who’s subscribed. You post the news to the newsstand. Everyone interested automatically gets it.

That’s Pub/Sub Architecture 🎯

Why?

→ No direct connections: Publishers don’t need to know subscribers. Just post to the newsstand.

→ Scales easily: Add 1,000 new subscribers? Doesn’t matter. The publisher still just posts once.

→ Asynchronous: Publishers don’t wait. Subscribers pick up messages whenever they want.

→ Flexible: Subscribers can change interests anytime (unsubscribe from one topic, subscribe to another).

→ Reliable: The newsstand (message broker) ensures everyone gets their news, even if they miss it the first time.

How?

First, Let’s Understand: What is a Topic?

A Topic is like a labelled mailbox or category channel.

Think of it this way:

• 📬 Instead of one big mailbox for all news, there are separate labelled boxes: “Sports”, “Weather”, “Politics”
• Publishers put their messages into the correct mailbox based on their content.
• Subscribers only open the mailboxes they care about
• A message about cricket goes to the “Sports” mailbox, not the “Weather” mailbox

Real-world analogy:

• YouTube channels are topics (subscribe to “Tech Channel”, “Gaming Channel”, “Music Channel”)
• Telegram groups are topics (join “Sports Group”, “News Group”)
• Email folders are topics (Inbox, Promotions, Updates)

So when a publisher sends a message about cricket, they send it to the “Sports” topic, not to individual subscribers.

Step 1: Publisher Creates a Message

A sports reporter writes: “India wins cricket match!”

Step 2: Publish to a Topic

The publisher sends this message to the “Sports” topic on the message broker. (Not directly to people, but to the topic/category)

Step 3: Subscribers Receive

Everyone subscribed to “Sports” automatically gets the notification.

• Cricket fans see it
• Sports reporters see it.
• TV channels see it
• No one else is bothered.

Step 4: Asynchronous Magic

The publisher doesn’t wait for anyone to read. Subscribers get it whenever they check.

Key Components

Publisher 📰

• What it does: Creates and sends messages.
• Example: Newspaper publishing company

Topic 🏷️

• What it does: A named channel for messages
• Example: “Sports”, “Weather”, “Politics”

Message Broker 🏪

• What it does: Central hub that routes messages
• Example: The newsstand (connects everything)

Subscriber 👤

• What it does: Listens to topics they care about
• Example: A person who subscribes to sports news

Message 💬

• What it does: The actual content being shared.
• Example: “India wins cricket match!”

Subscription 📋

• What it does: The link between subscriber and topic
• Example: Your sports news subscription

The Flow (Simple Diagram)

Real-World Example: Twitter/X

When you tweet:

1. You’re the publisher → You write and post your tweet.
2. Topic is your profile → Your tweets go to a “Your Name” topic.
3. Message broker is Twitter’s backend → Routes your tweet to all followers.
4. Your followers are subscribers → They automatically see your tweet in their feed.
5. You don’t know who follows you → You just post; followers appear.
6. It’s asynchronous → Followers see tweets whenever they open the app

The magic? You don’t send tweets to each follower individually. You post once, and the system broadcasts it to everyone interested.

Pub/Sub vs Point-to-Point (What’s the Difference?)

Point-to-Point ❌

• Like sending a letter directly to a specific person.
• You know the address (must know the recipient).
• One sender, one receiver.
• Tight coupling.
• Example: SMS, Email.

Pub/Sub ✅

• Like posting on a bulletin board for anyone interested
• You don’t know who reads it.
• One publisher, many subscribers.
• Loose coupling.
• Example: Twitter, Telegram channel, notification system.

Types of Pub/Sub Services

Standard Pub/Sub

✅ High reliability.
✅ Automatic scaling.
✅ Data replicated to multiple zones.
✅ Best for: Critical applications.
❌ More expensive.

Pub/Sub Lite

✅ Cost-effective.
✅ Good enough for most cases.
⚠️ Less reliability.
⚠️ You manage capacity.
✅ Best for: Budget-conscious projects.

When Should You Use Pub/Sub?

✅ Real-time notifications → Breaking news, stock alerts, user notifications.

Get Er. Hardik’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

✅ Multiple services care about the same event → Order placed → Payment, Shipping, and Email all need to know.

✅ You want to scale easily → Add new subscribers without changing the publisher.

✅ Asynchronous is fine → You don’t need instant replies.

✅ Loosely coupled systems → Services should work independently.

❌ NOT for → When you need strict message ordering, synchronous responses, or very low latency.

Comparison with Other Patterns (Pub/Sub vs Everything Else)

Pub/Sub Architecture 📡

• Use Case: Broadcasting one message to many subscribers.
• Speed: Asynchronous (slightly slower, but fine for most apps).
• Message Order: No guarantee (messages might arrive out of order).
• Coupling: Loose ✅ (publishers & subscribers don’t know each other).
• Best For: Events, notifications, and multiple services needing the same update.
• Example: Twitter followers getting your tweet.

Message Queue 📦

• Use Case: Sending tasks from one service to another
• Speed: Asynchronous (slower, but reliable)
• Message Order: Guaranteed (messages arrive in order)
• Coupling: Loose ✅ (services don’t know each other)
• Best For: Task processing, job queues
• Example: RabbitMQ, AWS SQS

WebSockets 🔌

• Use Case: Real-time bidirectional communication
• Speed: Synchronous (very fast, instant)
• Message Order: No guarantee
• Coupling: Tight ❌ (client & server must connect directly)
• Best For: Live chat, real-time games, notifications
• Example: Discord chat, Google Meet

HTTP APIs 🌐

• Use Case: Request-response communication
• Speed: Synchronous (fast, but slower than WebSockets)
• Message Order: N/A (one request, one response)
• Coupling: Tight ❌ (client must know server URL)
• Best For: Traditional web requests
• Example: REST APIs, weather API calls

Streaming (Kafka) 🌊

• Use Case: Continuous data processing with long-term retention
• Speed: Asynchronous (fast, optimized for high throughput)
• Message Order: Guaranteed (within a partition)
• Coupling: Loose ✅ (producers & consumers independent)
• Best For: Big data, analytics, event logs, audit trails
• Example: Netflix logs, financial data streams

The Bottom Line

Pub/Sub = One-to-Many Broadcasting

Instead of:

• ❌ “I need to tell each person individually” (point-to-point)
• ❌ “Everyone bugs me for updates” (polling)

You get:

• ✅ “I post once, everyone interested gets it”
• ✅ “They can come back anytime to check”
• ✅ “New people can join anytime”
• ✅ “I never need to change my code”

It’s like having a newspaper delivery system where:

• 📰 You (publisher) just write the news
• 🏪 A newsstand (message broker) distributes it
• 👥 Readers (subscribers) pick up what they want
• 🤝 Nobody talks to each other directly

Perfect for building scalable, flexible, loosely-coupled systems.

Credit to @SuhailKakar for the ELI5 explanation style