# Pub/Sub

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/pub-sub

## Quick definition

Pub/Sub stands for publish/subscribe. It is a way for different parts of a system to communicate with each other without being directly connected. One component sends a message and many other components can receive it if they have subscribed to that type of message. This makes the system more flexible and reliable.

## Simple meaning

Imagine you are in a large office building and there is a public announcement system. The building manager can make an announcement over the loudspeakers, like “Fire drill at 3 PM.” Every person in the building hears the announcement, but only the people who care about fire drills pay attention. The manager does not need to know who is listening or go to each person individually. In Pub/Sub, publishers are like the building manager. They send out a message without knowing exactly who will receive it. Subscribers are like the employees who choose to listen to certain types of announcements. They can decide to listen to fire drill announcements but ignore other announcements like a lost cat. This separation is powerful because it means the publisher and subscriber do not need to know about each other. They are decoupled. In computer systems, this pattern is used in many places. For example, a sensor on a factory machine might publish temperature readings. A monitoring dashboard, a logging system, and an alerting system can all subscribe to those temperature readings. Each system does its own job without interfering with the others. This pattern also helps when systems get very large. Publishers and subscribers can be added or removed without breaking anything. It also helps with reliability, because if a subscriber goes offline, messages can be stored until it comes back. Pub/Sub is a foundational idea in modern cloud computing, microservices, and event-driven architectures.

## Technical definition

Pub/Sub, or publish/subscribe, is an asynchronous messaging pattern that decouples message producers (publishers) from message consumers (subscribers) through an intermediary called a broker or event bus. In this pattern, publishers send messages to topics or channels, and subscribers express interest in specific topics by subscribing to them. The broker is responsible for receiving messages from publishers, filtering them based on topic subscriptions, and delivering them to all active subscribers. This model supports one-to-many, many-to-many, and many-to-one communication, making it highly scalable.

The core components of a Pub/Sub system include publishers, subscribers, topics, and brokers. A topic is a named logical channel to which publishers send messages. Subscribers register interest in one or more topics. The broker manages routing, message delivery, and often persistence. There are two main delivery models: push and pull. In the push model, the broker actively sends messages to subscribers as soon as they are available. In the pull model, subscribers request messages from the broker at their own pace. Many modern systems, such as Google Cloud Pub/Sub and Amazon SNS, support both modes.

Protocols used in Pub/Sub include MQTT, AMQP, and STOMP. MQTT is lightweight and ideal for IoT devices. AMQP is a feature-rich protocol used in enterprise message brokers like RabbitMQ. STOMP is a simple, text-oriented protocol. In cloud environments, Pub/Sub services often provide at-least-once delivery guarantees, meaning a message is delivered at least once, though duplicates are possible. Ordering guarantees vary: some systems preserve message order within a partition, while others do not.

Real IT implementations use Pub/Sub for event-driven architectures, microservices communication, log aggregation, data streaming, and serverless computing. For example, an e-commerce platform might publish an “order placed” event to a topic. Subscribers might include an inventory service to update stock, a shipping service to create a shipment, and an analytics service to record the order. This avoids tight coupling between services and allows independent scaling. Cloud-based Pub/Sub services also offer features like dead letter queues, retry policies, and message filtering. In modern IT infrastructure, Pub/Sub is essential for building responsive, resilient, and scalable distributed systems.

## Real-life example

Think about subscribing to a podcast. You do not call the podcaster and ask them to call you every time a new episode is out. Instead, you subscribe to the podcast through an app like Apple Podcasts or Spotify. The podcaster publishes a new episode to their hosting platform. The platform then makes that episode available to everyone who is subscribed. You open your app and see the new episode waiting for you. You can listen to it whenever you want, or you can let the app download it automatically. The podcaster never has to know your phone number, your name, or even that you exist. You, as a subscriber, only get the content you care about (that specific podcast) and not everything else the host might create. In this analogy, the podcaster is the publisher, the podcast hosting platform is the broker, the podcast feed is the topic, and you are the subscriber. The publisher sends the message (episode) to the topic (podcast feed) through the broker (hosting platform). The broker stores the message and delivers it to all subscribers. If you unsubscribe, you stop receiving future episodes, but the podcaster does not need to change anything. This matches exactly how Pub/Sub works in IT. Publishers send events to a topic, and the broker handles delivery to subscribers. Subscribers can come and go without affecting the publisher.

## Why it matters

Pub/Sub matters because modern applications are increasingly distributed and need to communicate efficiently. In monolithic applications, all components run in one process, so calling a function is simple. But as systems grow into microservices and cloud-native architectures, components run on different servers, containers, or even different cloud regions. Direct point-to-point communication creates tight coupling, meaning if one service fails, others break. Pub/Sub solves this by decoupling services. A publisher service can emit an event without caring which services consume it. This makes the system more resilient because a subscriber can fail without affecting the publisher. It also makes the system more scalable, because multiple subscriber instances can process messages in parallel.

In practical IT, Pub/Sub is used for critical tasks: sending notifications, updating caches, syncing databases, processing logs, and handling IoT data. For example, a web application might publish a “user signed up” event. Subscribers can trigger a welcome email, create a user profile, update a CRM, and add the user to a mailing list. Each of these tasks can be done independently and asynchronously, keeping the main application fast and responsive. Pub/Sub also supports integration between different systems, such as connecting on-premises databases to cloud analytics tools. Without Pub/Sub, developers would have to write complex code for polling, queuing, and error handling. Pub/Sub provides a standardized, reliable, and often managed solution for these problems. For IT professionals, understanding Pub/Sub is essential for designing scalable, resilient architectures and passing cloud certification exams like AWS Certified Solutions Architect, Google Cloud Associate, or Microsoft Azure fundamentals.

## Why it matters in exams

Pub/Sub appears in several major certification exams, including AWS Certified Solutions Architect, Google Cloud Associate Cloud Engineer, Google Cloud Professional Data Engineer, and Microsoft Azure Fundamentals. In AWS, the related service is Amazon Simple Notification Service (SNS). In Google Cloud, it is Cloud Pub/Sub. In Azure, similar functionality is provided by Azure Event Grid and Azure Service Bus. These exams test understanding of messaging patterns, decoupling, and asynchronous communication.

For AWS exams, expect questions about when to use SNS versus SQS versus Kinesis. SNS is the Pub/Sub service. Common exam scenarios: you need to send a notification to multiple subscribers, like email, SMS, and HTTP endpoints. You will use SNS with a topic. You might need to filter messages using subscription filter policies. Questions also cover fan-out patterns, where SNS publishes to multiple SQS queues. In the Google Cloud Associate exam, Cloud Pub/Sub questions focus on topics, subscriptions, push vs pull delivery, and message retention. You might be asked to design a system where an application publishes events that are processed by multiple workers. The correct answer will involve Cloud Pub/Sub with a pull subscription for fault tolerance. For the Professional Data Engineer exam, Pub/Sub is crucial for designing streaming data pipelines. Questions cover ordering guarantees, exactly-once delivery, and handling large message volumes.

In Azure exams, Event Grid is the primary Pub/Sub service. Questions often involve reacting to Azure resource events (like a storage blob created) or custom events. The correct design might use Event Grid to trigger a function app. Service Bus with Topics is also covered for enterprise messaging. Exam objectives include comparing messaging services and choosing the right one for a given scenario. Across all exams, the key concepts tested are decoupling, fan-out, async communication, scalability, and message persistence. Make sure you understand the differences between push and pull, at-least-once vs exactly-once delivery, and ordering guarantees.

## How it appears in exam questions

Exam questions about Pub/Sub typically fall into two categories: scenario-based design questions and configuration or troubleshooting questions. Scenario questions present a business requirement and ask which service or pattern to use. For example: “A company has an e-commerce application. When a customer places an order, the system must update the inventory database, send a confirmation email, and notify a third-party shipping service. The system must be decoupled and scalable. Which approach should the company use?” The correct answer would involve a Pub/Sub pattern, such as publishing an “order placed” event to a topic that multiple subscribers consume. Wrong answers might include direct service calls (tight coupling) or a single queue (which does not fan out to multiple consumers).

Configuration questions might ask: “An application needs to receive messages from a Pub/Sub topic, but messages must be processed in the order they were published. Which subscription type should you use?” The answer is a subscription that preserves ordering, like a pull subscription with exactly-once delivery. In AWS, you might be asked about SNS subscription filter policies. For example: “You have an SNS topic that publishes order events. Only orders with total > $100 should be sent to a premium processing queue. How can you achieve this?” The answer is to add a filter policy on the subscription to the SQS queue.

Troubleshooting questions might describe a symptom: “Messages are not being delivered to a subscriber. What could be the issue?” Possible causes: the subscriber endpoint is not responding, the subscription is paused, the message retention period has expired, or the subscriber has not confirmed the subscription (for HTTP/HTTPS endpoints). In Google Cloud, a common issue is that the publisher is publishing to the wrong topic or the subscriber is subscribing to a different topic. Understanding these patterns will help you quickly eliminate incorrect answers.

## Example scenario

A company named QuickCart runs an online store. Every time a customer buys something, many things need to happen: inventory levels must be updated, a confirmation email must be sent, the shipping department must create a label, and a receipt must be saved for accounting. In the old system, the checkout service directly called each of these other services. If the email service was slow, the entire checkout process slowed down. If the inventory service crashed, the checkout failed entirely.

QuickCart decides to redesign using Pub/Sub. They create a Pub/Sub topic called “order_placed.” When a customer checks out, the checkout service publishes a single message to this topic. The message contains the order details. Now, separately, three subscriber services are set up: the inventory subscriber, the email subscriber, and the shipping subscriber. Each subscriber is subscribed to the “order_placed” topic. The inventory subscriber runs a worker that reads messages from its subscription, updates the database, and removes the bought items. The email subscriber picks up the same message and sends the confirmation. The shipping subscriber creates the label. Because of Pub/Sub, the checkout service does not need to know about any of these downstream services. If the email service is down for maintenance, the other subscribers still work. Messages for the email subscriber will be retained in the subscription until it comes back online. QuickCart can also add new subscribers later, like a loyalty points service, without changing the checkout code. This decoupled, resilient approach is exactly what exam questions test.

## Common mistakes

- **Mistake:** Thinking that Pub/Sub is the same as a message queue.
  - Why it is wrong: In a message queue, each message is consumed by only one consumer. In Pub/Sub, each message is delivered to all subscribers. They serve different patterns.
  - Fix: Use a queue for point-to-point communication and Pub/Sub for fan-out to multiple consumers.
- **Mistake:** Confusing synchronous and asynchronous communication.
  - Why it is wrong: Pub/Sub is inherently asynchronous. Some learners think the publisher waits for a response from the subscriber. That is wrong. The publisher sends a message and continues without waiting.
  - Fix: Remember that Pub/Sub is fire-and-forget for the publisher. Subscribers process messages independently.
- **Mistake:** Ignoring message ordering and duplication.
  - Why it is wrong: Many Pub/Sub systems offer at-least-once delivery, which can cause duplicates. Also, ordering is not always guaranteed. Learners often assume all messages arrive in order exactly once.
  - Fix: Check the documentation for ordering and delivery guarantees. Design subscribers to be idempotent if duplicates are possible.
- **Mistake:** Believing that Pub/Sub requires a broker in the same data center.
  - Why it is wrong: Cloud Pub/Sub services like Google Cloud Pub/Sub and Amazon SNS are global and managed. They can handle messages across regions.
  - Fix: Understand that cloud Pub/Sub services are fully managed and scale automatically, even globally.
- **Mistake:** Using Pub/Sub for all communication needs, including request-response.
  - Why it is wrong: Pub/Sub is not ideal for request-response patterns because it is one-way. Using it for that adds complexity.
  - Fix: For request-response, use synchronous calls or an RPC pattern. Reserve Pub/Sub for events and notifications.

## Exam trap

{"trap":"Choosing a message queue (like SQS or Cloud Tasks) when the requirement is to send the same message to multiple independent consumers.","why_learners_choose_it":"Learners see the word “message” and “decouple” and think a queue is always the answer. They forget that queues are for one consumer per message.","how_to_avoid_it":"If the scenario says “multiple consumers must process each event independently” or “fan-out”, always choose Pub/Sub (like SNS or Cloud Pub/Sub). A queue is only correct when exactly one consumer processes each message."}

## Commonly confused with

- **Pub/Sub vs Message Queue (e.g., AWS SQS, Google Cloud Tasks):** A message queue delivers each message to exactly one consumer. Pub/Sub delivers each message to all subscribers. Queues are for point-to-point, Pub/Sub for broadcast. (Example: Using SQS for processing orders one by one vs using SNS to send order notifications to both email and SMS systems.)
- **Pub/Sub vs Event Bus (e.g., AWS EventBridge):** An event bus is a type of Pub/Sub but often includes schema registry, filtering, and routing based on event content. Standard Pub/Sub topics route based on topic name only. Event buses offer more powerful filtering. (Example: EventBridge can route “order placed” events only when order value > $100 to a specific target, whereas a simple Pub/Sub topic would send all order placed events.)
- **Pub/Sub vs Streaming (e.g., Apache Kafka, AWS Kinesis):** Streaming systems store a log of messages that multiple consumers can replay from any point. Pub/Sub is typically ephemeral: messages are removed after delivery. Streaming retains messages for longer and supports replay. (Example: Kafka is used for building event logs and data pipelines where you need to reprocess old data; Pub/Sub is for real-time event notification.)

## Step-by-step breakdown

1. **Publisher creates a message.** — The publisher application generates a piece of data, often in JSON or bytes, that represents an event or notification. This message includes a payload and optional attributes.
2. **Publisher sends the message to a topic.** — The publisher chooses a specific topic name that categorizes the message, like “image_uploaded.” The publisher does not know who will receive it.
3. **The broker receives the message and stores it temporarily.** — The Pub/Sub broker (e.g., Google Cloud Pub/Sub or SNS) accepts the message, assigns a unique ID, and holds it in the topic. Message retention is configurable.
4. **The broker delivers the message to active subscriptions.** — Each subscription represents a named endpoint that subscribes to the topic. The broker sends a copy of the message to each subscription. This is the fan-out behavior.
5. **Subscriber receives the message from its subscription.** — Each subscriber pulls or pushes the message. In pull mode, the subscriber requests the next message. In push mode, the broker sends it to a configured webhook. The subscriber processes the message.
6. **Subscriber acknowledges the message.** — After successful processing, the subscriber sends an acknowledgment to the broker. The broker then deletes the message from the subscription. If no ack is received within a timeout, the message is redelivered.

## Practical mini-lesson

To work effectively with Pub/Sub in a professional IT environment, you must understand the core design decisions. First, choose between push and pull delivery. Pull delivery is common when subscribers need to control the processing rate or when the subscriber is an internal service. Push is used when the subscriber is an external endpoint or serverless function that should be triggered immediately. In Google Cloud Pub/Sub, pull subscriptions are used by worker services, while push sends messages to HTTPS endpoints. In AWS, SNS uses push for all subscribers, but you can use SQS queues as subscribers to achieve pull-like behavior.

Message ordering is another critical aspect. Most cloud Pub/Sub services do not guarantee global ordering unless you use ordering keys or partitions. Google Cloud Pub/Sub offers message ordering by setting an ordering key on messages within a region. AWS SNS does not guarantee order. If your application requires strict processing order, consider using a stream like Kafka or Kinesis, or design your system to handle out-of-order messages.

Idempotency is vital because at-least-once delivery means a subscriber might receive the same message twice. Your subscriber code should detect and discard duplicates, for example by tracking message IDs. This is a common exam and real-world consideration.

Error handling: set up dead letter queues (DLQs) for messages that cannot be processed after a certain number of retries. In Google Cloud Pub/Sub, you can attach a dead letter topic to a subscription. In AWS, use SNS DLQs. This prevents message loss and helps debugging.

Finally, monitoring: track metrics like publish count, delivery rate, subscription backlog, and ack deadlines. If backlog grows, you need more subscribers or faster processing. Understanding these operational details sets apart a skilled professional from a beginner and is precisely what certification exams evaluate in design and troubleshooting questions.

## Memory tip

Think “Topic = TV channel, Subscriber = viewer. Publisher broadcasts, all viewers get the show.”

## FAQ

**What is the difference between Pub/Sub and message queues?**

A message queue delivers each message to one consumer only. Pub/Sub delivers each message to all subscribers. Use Pub/Sub when you need the same event to be processed by multiple independent systems.

**Is Pub/Sub synchronous or asynchronous?**

Pub/Sub is asynchronous. The publisher sends a message and continues without waiting for subscribers to process it.

**What does “at least once delivery” mean in Pub/Sub?**

It means the system guarantees the message will be delivered to the subscriber at least once, but it might be delivered more than once. Subscribers should be designed to handle duplicates.

**Can I guarantee message order in Pub/Sub?**

Some Pub/Sub services support ordering within a partition or using ordering keys, but global ordering is not guaranteed. If strict order is needed, consider using a streaming platform like Kafka.

**What is a dead letter queue in Pub/Sub?**

A dead letter queue is a destination where messages are sent if they cannot be processed successfully after a set number of retries. It prevents message loss and helps with debugging.

**What is the difference between push and pull in Pub/Sub?**

In push delivery, the broker actively sends the message to a subscriber endpoint. In pull delivery, the subscriber requests messages from the broker. Pull gives the subscriber more control over processing pace.

## Summary

Pub/Sub is a fundamental messaging pattern used in modern IT systems to decouple services and enable scalable, asynchronous communication. Publishers send messages to topics, and multiple subscribers receive copies of each message. This pattern is essential for building event-driven architectures and cloud-native applications. It appears on major certification exams for AWS, Google Cloud, and Azure. Exam questions test your ability to choose between Pub/Sub and other messaging services like message queues or streaming platforms.

To succeed, remember that Pub/Sub is for fan-out scenarios where the same event must reach multiple independent consumers. Always check for at-least-once delivery and design for idempotency. Understand the difference between push and pull delivery, and know how to configure filtering and ordering if needed. Cloud providers offer fully managed Pub/Sub services that simplify scaling and reliability.

The key exam takeaway: when you see a requirement for “multiple services need to process the same event independently”, think Pub/Sub. When you see “process each task exactly once”, think queue. Master this distinction and you will handle Pub/Sub questions confidently.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/pub-sub