---
id: 6a1ff130175dfa251ad1e1ca
title: What is the Pub/Sub Architecture?
challengeType: 19
dashedName: what-is-the-pub-sub-architecture
---

# --description--

Pub/Sub stands for **Publish/Subscribe**.

It is a messaging architecture that allows different parts of a system to communicate without knowing about each other directly.

At first glance, that might sound complicated, but you've already seen similar systems in everyday life.

Think about YouTube.

When a creator/channel admin uploads a new video, they don't send it directly to every subscriber. Instead, they publish the video onto their channel. Anyone who has subscribed to that channel receives a notification about the new upload.

The creator doesn't need to know who the subscribers are, and the subscribers don't need to contact the creator directly. The platform handles everything in between.

Pub/Sub works in a similar way. There are three main parts involved:

- Publishers
- Topics (or channels, or groups, as is on WhatsApp)
- Subscribers

A **publisher** sends messages. A **subscriber** receives messages. A **topic** acts as the middleman between them.

The flow looks like this:

1. A subscriber subscribes to a topic.
2. A publisher sends a message to that topic.
3. The messaging system delivers the message to every subscriber of that topic.

For example, imagine a sports news application. Users can subscribe to a topic or their team of choice, say `football-updates`, or `chelsea fc`.

Whenever a match event occurs, such as a goal or red card, the system publishes a message to that topic. When Chelsea FC scores or concedes a goal, every user subscribed to `chelsea fc` immediately receives the update.

The publisher does not need to know who the subscribers are. It only needs to know where to publish the message.

This separation is one of the biggest advantages of the Pub/Sub architecture. Without Pub/Sub, systems often communicate directly. The flow might look like this:

`Application A → Application B`

This works, but it creates an unnecessary dependency between the applications. If Application B changes or becomes unavailable, Application A may stop working properly.

With Pub/Sub, the flow changes to:

`Application A → Topic → Subscribers`

Now Application A only publishes messages. It doesn't need to know who receives them.

Another example is a chat application with multiple chat rooms or groups. Users in Room A subscribe to `room-a`. Users in Room B subscribe to `room-b`.

When someone sends a message in Room A, the application publishes that message to `room-a`. Only subscribers of `room-a` receive the message, and those in Room B never see it.

This way, the systems are easier to maintain, expand, and scale.

This is one of the reasons Pub/Sub appears so often in chat applications, multiplayer games, notification systems, live dashboards, and event-driven applications.

It's also important to understand that Pub/Sub and WebSockets are not the same thing. WebSockets provide the communication channel that allows data to move between a client and a server in real time. Pub/Sub provides the messaging pattern that determines who should receive specific messages.

You can think of it this way:

- WebSockets are the road.
- Pub/Sub is the traffic system that decides where vehicles should go.

Many modern real-time applications use both technologies together. WebSockets keep the connection open, while Pub/Sub ensures messages reach the right subscribers.

The key idea behind Pub/Sub is that publishers send messages to topics, and subscribers listen to topics. The messaging system handles the delivery between them.

# --questions--

## --text--

What are the three main parts involved in a Pub/Sub messaging architecture?

## --answers--

Senders, queues, and consumers.

### --feedback--

Think about who sends, what acts as the middleman, and who receives.

---

Producers, brokers, and listeners.

### --feedback--

Think about who sends, what acts as the middleman, and who receives.

---

Clients, servers, and databases.

### --feedback--

Think about who sends, what acts as the middleman, and who receives.

---

Publishers, topics, and subscribers.

## --video-solution--

4

---

## --text--

What is the primary advantage of using Pub/Sub over direct communication between applications?

## --answers--

It reduces the total number of messages sent across the network.

### --feedback--

The text mentions that without Pub/Sub, a change or failure in one app can break another.

---

It eliminates the dependency between publisher and subscriber.

---

It automatically encrypts all transmitted data.

### --feedback--

The text mentions that without Pub/Sub, a change or failure in one app can break another.

---

It requires less memory on the server side.

### --feedback--

The text mentions that without Pub/Sub, a change or failure in one app can break another.

## --video-solution--

2

---

## --text--

How do Pub/Sub and WebSockets differ from each other in a real-time application?

## --answers--

WebSockets provide the communication channel, and Pub/Sub provides the message pattern.

---

WebSockets handle authentication, while Pub/Sub handles data storage.

### --feedback--

One is like the road, the other is like the traffic system directing where messages go.

---

Pub/Sub is for mobile apps, and WebSockets are for desktop browsers only.

### --feedback--

One is like the road, the other is like the traffic system directing where messages go.

---

They are identical technologies with different names.

### --feedback--

One is like the road, the other is like the traffic system directing where messages go.

## --video-solution--

1
