If you have ever built a system where one service needs to wait for another service to finish before it can do its job, you have experienced the pain of tight coupling. Imagine a customer placing an order on a website, and the entire checkout process freezing until the warehouse confirms the item is in stock — that is slow, fragile, and frustrating. Pub/Sub and event-driven integration solve this by letting services send messages into a central channel and walk away, so other services can pick up those messages whenever they are ready, completely independently.
Jump to a section
A simple way to picture Pub/Sub and Event-Driven Integration
12 people in a neighbourhood decide to organise a community potluck dinner. Everyone cooks a dish, but instead of bringing it to one central table where people queue up and grab food directly from the cooks, they set up a 'message board' system. Each cook writes the name of their dish on a card and pins it to a big corkboard in the hallway. Then each resident who wants to eat walks to the board, reads all the cards, and picks the dishes they are interested in. The cook never knows who ate their food or how many people chose it. The cook just cooks, pins the card, and goes home. The eaters arrive at different times, read the board, and serve themselves from the dishes that are still available. If a cook makes a second batch, they pin a new card. If an eater arrives three hours late, they still find the cards on the board and can help themselves. This is exactly what Pub/Sub does: the cook (publisher) sends a message (the card) to a topic (the corkboard) and subscribers (the eaters) pick messages when they are ready. Nobody waits for anyone else. The system works even if some eaters show up late or if multiple cooks post at the exact same time.
The key insight is that the corkboard decouples the cooks from the eaters. The cook does not need to know how many eaters exist, when they will arrive, or what they will choose. The eaters do not need to know which cook made which dish — they just see the cards. If a new eater moves into the neighbourhood next week, they can start reading the board without the cook having to do anything differently. That is the entire magic of Pub/Sub: send once, receive many times, and the sender and receiver never need to know each other exist.
Pub/Sub stands for Publish/Subscribe. It is a messaging pattern where one piece of software (the publisher) sends a message to a central topic, and zero or more other pieces of software (the subscribers) receive copies of that message. The publisher does not know who the subscribers are, how many there are, or whether they even exist. The subscribers do not know who published the message. The topic acts as a middleman that decouples both sides.
To understand why this matters, think about the alternative: a direct call. In a direct call, Service A sends a request directly to Service B and waits for a response. If Service B is slow or down, Service A is stuck waiting. If you add Service C that also needs the same data, you have to change Service A to call Service C as well. This is called tight coupling, and it makes systems fragile, hard to change, and difficult to scale.
Pub/Sub replaces direct calls with asynchronous messaging. Asynchronous means the sender does not wait for the receiver. The publisher sends the message and immediately moves on to its next task. The subscriber processes the message later, whenever it has capacity. This creates a fault-tolerant, scalable architecture.
Here is how it works in Google Cloud. You create a topic, which is a named resource that messages are sent to. Then you create one or more subscriptions, which are named resources that pull messages from the topic. A publisher sends a message to the topic. The topic holds the message temporarily. Each subscription receives a copy of that message. Subscribers are applications that pull messages from their subscription, process them, and then acknowledge them. Acknowledgement tells Pub/Sub that the message was successfully processed. If a subscriber crashes before acknowledging, Pub/Sub redelivers the message to another subscriber.
Key terms you need to know:
Publisher: the application that sends messages. It only needs to know the topic ID.
Topic: the named channel where messages are sent. Think of it like a postbox.
Message: the data being sent. It has a payload (the actual data, like a JSON object) and optional attributes (key-value pairs for metadata).
Subscription: a named resource that pulls messages from a topic. You can have multiple subscriptions on the same topic.
Subscriber: the application that receives messages from a subscription. It can be a Cloud Function, a Compute Engine instance, a container on Kubernetes, or any HTTP endpoint.
Acknowledgment (ACK): the signal the subscriber sends back to confirm it processed the message. Messages that are not acknowledged are redelivered.
Dead letter topic: a separate topic that messages are moved to if they keep failing to be processed after a set number of attempts. This prevents bad messages from blocking the queue forever.
What does this replace? Traditional systems used point-to-point integration, where every service had to know how to talk to every other service. That creates a spiderweb of dependencies. Pub/Sub replaces that with a star pattern: all messages flow through the topic, and any service can subscribe to any topic without the publisher changing.
Another thing Pub/Sub replaces is polling. Without Pub/Sub, a service might have to repeatedly check a database table (poll) to see if new work exists. This wastes compute resources and introduces latency. Pub/Sub pushes messages to subscribers or lets them pull only when messages are available, so no wasted cycles.
Event-driven integration is the broader architectural pattern where your system reacts to events — things that happened — rather than being driven by a central scheduler or direct requests. Pub/Sub is the most common tool for building event-driven systems. Instead of a service saying 'Please do X now', it says 'X happened' and leaves it to other services to decide what to do. For example, when a user signs up, a 'user.created' event is published. The email service subscribes to send a welcome email. The analytics service subscribes to log the event. The CRM service subscribes to create a contact record. All of this happens in parallel, without the signup service knowing about any of them.
In Google Cloud, Pub/Sub is a fully managed service, meaning Google handles all the infrastructure. You do not need to provision servers, manage queues, or worry about scaling. It automatically scales to handle millions of messages per second. It also supports exactly-once delivery semantics for some configurations, message ordering within a region, and message retention for up to 7 days if the subscriber is offline.
To sum up: Pub/Sub decouples publishers from subscribers, enables asynchronous communication, and is the backbone of event-driven architectures on Google Cloud. It makes your system more resilient, easier to change, and capable of handling unpredictable spikes in traffic without breaking.
Create a Topic
A topic is the named channel where publishers send messages. You create it in the Google Cloud console, via gcloud command line, or in code. The topic name must be unique within your project. This is the first building block because without a topic, messages have nowhere to go.
Create a Subscription
A subscription is the named resource that connects a subscriber to a topic. Each subscription receives every message published to the topic. You configure delivery type (push or pull), acknowledge deadline, message retention duration, and optionally a dead letter topic. Multiple subscriptions can exist on one topic for different consumers.
Publisher Sends a Message
The publisher application calls the Pub/Sub API with the topic name and the message data (usually a JSON string). The message can include attributes (key-value pairs) for metadata. Pub/Sub assigns a unique message ID and stores the message durably. The publisher does not wait for any subscriber — it immediately continues its own work.
Subscriber Pulls or Receives Message
If using pull delivery, the subscriber repeatedly requests messages from the subscription via the client library. If using push delivery, Pub/Sub sends an HTTPS POST request to a pre-configured endpoint. The subscriber receives the message data and attributes. This is where the actual work happens — processing the event, updating a database, calling another API, etc.
Subscriber Acknowledges the Message
After processing, the subscriber sends an acknowledgment (ACK) back to Pub/Sub. This tells Pub/Sub the message was handled successfully. If the subscriber crashes before acknowledging, Pub/Sub redelivers the message to the same subscription (or another subscriber on the same subscription). If the subscriber never ACKs and the acknowledge deadline passes, the message is made available again.
Handle Failures with Dead Letter Topic
If a message keeps failing (e.g., the subscriber throws an error every time), you can configure a dead letter topic on the subscription. After a set number of delivery attempts (e.g., 5), the message is moved to the dead letter topic. A separate process can then inspect dead letter messages, fix the underlying issue, and republish them. This prevents a single bad message from blocking the entire subscription.
You are the lead developer for an e-commerce platform called ShopCloud. The platform has three microservices: an Order Service that handles new orders, a Payment Service that processes payments, and a Notification Service that sends emails and SMS. Currently, the Order Service directly calls the Payment Service and waits for the payment result. Then it calls the Notification Service. If the Payment Service is slow, the whole checkout hangs. If you need to add a Fraud Detection Service, you have to rewrite the Order Service.
You decide to migrate to Pub/Sub for the checkout flow. Here is exactly what you do step by step:
Create a topic called 'order-created' in the Google Cloud console or via the gcloud command line.
Create a subscription for the Payment Service called 'order-created-payment-sub'. This subscription pulls messages from the 'order-created' topic.
Create a second subscription for the Notification Service called 'order-created-notification-sub'.
Create a third subscription for a new Fraud Detection Service called 'order-created-fraud-sub'.
Modify the Order Service: instead of calling Payment and Notification directly, the Order Service publishes a single message to the 'order-created' topic. The message body is a JSON object containing the order ID, customer ID, items, and total amount. The Order Service immediately returns a '200 OK' to the customer's browser and moves on.
Modify the Payment Service: it now pulls messages from its subscription, processes payment, and acknowledges the message. If payment fails, it publishes a new message to a 'payment-failed' topic that the Notification Service also subscribes to.
Modify the Notification Service: it pulls messages from its subscription and sends the relevant email or SMS. It acknowledges only after the message is sent successfully.
Deploy the Fraud Detection Service: it pulls from its subscription, analyses the order for fraud, and if it finds suspicious activity, publishes a 'fraud-alert' message to another topic.
Now when a customer places an order, the Order Service publishes one message and is done. All three downstream services process the message in parallel. If the Payment Service is down for maintenance, messages accumulate in the subscription and are processed when it comes back online. The customer never sees an error. If fraud detection takes 10 seconds, that is fine — it does not slow down the checkout.
What does an IT professional actually do with this? They design the topic and subscription structure, set up the IAM permissions so only authorised services can publish or subscribe, configure dead letter topics for failed messages, monitor subscription backlog (the number of unacknowledged messages), set up alerts for high backlog, and write the subscriber code that pulls, processes, and acknowledges messages. They also choose between push delivery (Pub/Sub sends messages to an HTTP endpoint) and pull delivery (the subscriber requests messages). They configure message retention and set up exactly-once delivery if needed for financial transactions.
Common actions you will take as a developer:
Use the gcloud pubsub topics create and gcloud pubsub subscriptions create commands.
Write subscriber code in Python, Java, Go, or Node.js using the Google Cloud Pub/Sub client library.
Set up a Cloud Function as a subscriber that triggers on new messages.
Configure a dead letter topic to handle poison pills (messages that cannot be processed).
Monitor the Pub/Sub dashboard for unacknowledged messages and publish request counts.
The Google Professional Cloud Developer exam tests Pub/Sub and event-driven integration in several specific ways. Expect 3-5 questions on this topic spread across the exam. The questions are scenario-based, asking you to choose the best integration pattern for a given situation.
Here is exactly what they love to test:
The difference between pull and push subscriptions. Pull means your subscriber requests messages from Pub/Sub. Push means Pub/Sub sends messages to a pre-configured HTTPS endpoint. The exam will give you a scenario (e.g., 'You have a Cloud Function that needs to be triggered by every new message') and ask which subscription type to use. The answer is almost always push for Cloud Functions, pull for long-running services.
Message ordering. Pub/Sub guarantees message ordering within a region when you enable message ordering on the subscription. The exam will test that ordering is not guaranteed by default. They will give you a scenario involving stock trades or financial transactions and ask how to preserve order. The answer is enable ordering on the subscription and use the same ordering key for related messages.
Exactly-once delivery. Pub/Sub supports exactly-once delivery for pull subscriptions when the subscriber acknowledges each message before the deadline. The exam will test the trade-offs: exactly-once increases latency and cost. They will give you a scenario where duplicate messages are acceptable (like logging) and ask if exactly-once is needed. The answer is no — use at-least-once for non-critical systems.
Dead letter topics. The exam will test what happens when a message repeatedly fails. The answer is it gets moved to a dead letter topic after the maximum number of delivery attempts. They will ask you to configure the dead letter topic and max delivery attempts.
IAM permissions for Pub/Sub. You need to know the roles: roles/pubsub.publisher allows publishing to a topic, roles/pubsub.subscriber allows pulling from a subscription. The exam will give you a scenario where a service account cannot publish or subscribe and ask which role to add.
Retention duration. Messages are retained for 7 days by default. If a subscriber is offline longer than that, messages are lost. The exam will test this limit.
Acknowledge deadline. Subscribers must acknowledge within a configurable deadline (default 10 seconds). If they do not, the message is redelivered. The exam will test that you can extend the deadline if processing takes longer.
Common traps they set:
Choosing a direct API call instead of Pub/Sub when the scenario involves time-independent processing. For example, 'User uploads a photo and needs a thumbnail generated'. Many candidates think 'the user needs an immediate response', but the correct answer is still Pub/Sub — the upload service can acknowledge immediately and let a worker generate the thumbnail asynchronously.
Thinking Pub/Sub guarantees order across all messages. It does not unless explicitly configured.
Confusing Pub/Sub with Cloud Tasks. Cloud Tasks is for executing a single task at a later time. Pub/Sub is for broadcasting an event to multiple subscribers. The exam loves to present both and ask which to use.
Key definitions to memorise:
Topic: a named resource to which messages are sent by publishers.
Subscription: a named resource representing the stream of messages from a single topic to be delivered to a subscriber.
Message: a combination of data and attributes that a publisher sends to a topic.
Acknowledgment: the signal from a subscriber indicating a message was processed.
Dead letter topic: a topic for messages that could not be processed.
Pub/Sub decouples publishers from subscribers, meaning the publisher never waits for the subscriber and neither service knows the other exists.
A message is not deleted until every subscription on the topic has acknowledged it, enabling fan-out to multiple independent consumers.
Message ordering must be explicitly enabled on a subscription using an ordering key; it is not guaranteed by default.
Messages that repeatedly fail processing are moved to a dead letter topic after a configurable number of delivery attempts.
Pub/Sub retains unacknowledged messages for up to 7 days, so subscribers that go offline will not lose messages if they return within that window.
Cloud Tasks is for one-to-one task execution with scheduling; Pub/Sub is for one-to-many event broadcasting.
Push subscriptions send messages to an HTTPS endpoint automatically; pull subscriptions require the subscriber to request messages.
IAM roles pubsub.publisher and pubsub.subscriber control who can publish to a topic and who can pull from a subscription.
Acknowledge deadline is configurable (default 10 seconds) and can be extended if a subscriber needs more time to process a message.
Pub/Sub is a fully managed service that automatically scales to millions of messages per second without any infrastructure provisioning.
These come up on the exam all the time. Here's how to tell them apart.
Pub/Sub
Broadcasts one message to multiple subscribers via a topic
Subscribers pull or push messages asynchronously
Best for event-driven architectures where many services react to the same event
Cloud Tasks
Delivers a single task to exactly one worker via a queue
Supports scheduling tasks for a specific future time
Best for one-to-one task execution with retries, like sending a reminder email
Pull Subscription
Subscriber requests messages from Pub/Sub via the client library
Subscriber must be constantly polling or using a long-lived connection
Better for high-throughput, long-running services that can control message flow
Push Subscription
Pub/Sub sends an HTTPS POST to a pre-configured endpoint
No polling required — ideal for serverless like Cloud Functions
Better for low-latency, event-driven triggers where the endpoint is always available
At-Least-Once Delivery
Message may be delivered more than once if acknowledgement is delayed
Lower latency and higher throughput
Suitable for non-critical systems where duplicates are tolerable (e.g., logging)
Exactly-Once Delivery
Message is delivered exactly once, eliminating duplicates
Higher latency and lower throughput due to additional checks
Suitable for financial transactions or systems where duplicates cause errors
Pub/Sub
Fully managed, serverless, no capacity planning needed
Automatically scales to millions of messages per second
Best for most applications — no infrastructure management
Cloud Pub/Sub Lite
Requires you to pre-provision partitions and capacity
Fixed throughput and storage — you pay for what you provision
Best for known, predictable workloads with strict cost controls
Mistake
Pub/Sub guarantees that messages are delivered in the exact order they were published, across all subscriptions, by default.
Correct
Pub/Sub only guarantees message ordering if you explicitly enable message ordering on the subscription and use the same ordering key. By default, messages can arrive out of order.
People assume because Pub/Sub is a queue-like system, it preserves order like a FIFO queue. But Pub/Sub is a fan-out system, not a queue, and ordering is an opt-in feature with performance trade-offs.
Mistake
A message is deleted from the topic as soon as one subscriber acknowledges it.
Correct
A message remains on the topic until every subscription has acknowledged that message. Each subscription gets its own copy. One subscriber acknowledging does not affect other subscriptions.
This misconception comes from confusing Pub/Sub with a message queue like RabbitMQ where a message is consumed by one consumer. Pub/Sub is pub-sub, not queue, so messages are fanned out to all subscriptions.
Mistake
Pub/Sub is only useful for sending data between microservices within the same project.
Correct
Pub/Sub can send messages across projects, across regions, and even to external systems via push endpoints. You can publish from one project and subscribe from another project using cross-project IAM permissions.
Beginners often assume Google Cloud services are siloed. They do not realise Pub/Sub topics and subscriptions can be in different projects, enabling multi-team architectures.
Mistake
If a subscriber crashes and restarts, all unprocessed messages are lost.
Correct
Messages remain in the subscription for up to 7 days (the retention period). When the subscriber comes back, it pulls and processes the backlog of unacknowledged messages. No messages are lost unless the retention period expires.
People think of messaging systems as memory-based or ephemeral. They do not understand that Pub/Sub stores messages durably on disk across multiple zones.
Mistake
Pub/Sub and Cloud Tasks are interchangeable and can be used for the same scenarios.
Correct
Pub/Sub is for broadcasting events to multiple subscribers. Cloud Tasks is for executing a single task exactly once at a scheduled time. They serve different purposes.
Both handle asynchronous work, so beginners lump them together. But Cloud Tasks is designed for one-to-one task execution with retries, while Pub/Sub is one-to-many event distribution.
Mistake
Publishers must wait for subscribers to acknowledge before sending the next message.
Correct
Publishers send messages and immediately continue their work. They have no knowledge of subscribers or acknowledgements. The publisher and subscriber are completely decoupled.
The term 'publish/subscribe' sounds like a handshake. Beginners assume the publisher checks for a response, but the whole point is asynchronous decoupling.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A message queue delivers each message to exactly one consumer (like a ticket at a deli counter — one person takes it). Pub/Sub delivers each message to every subscription (like a public announcement — everyone hears it). Pub/Sub is for broadcasting events to multiple independent services.
Yes, but only for pull subscriptions when using exactly-once delivery mode, which prevents duplicates at the cost of higher latency and lower throughput. By default, Pub/Sub uses at-least-once delivery, meaning a message might be delivered more than once.
Use a dedicated topic for that subscriber. Each subscription on a topic gets all messages. To send to only one subscriber, create a topic with a single subscription for that subscriber. Alternatively, use Cloud Tasks, which is designed for one-to-one task execution.
If the subscriber does not acknowledge within the deadline (default 10 seconds), Pub/Sub considers the message undelivered and redelivers it to another subscriber on the same subscription, or to the same subscriber if no others exist. You can increase the deadline up to 600 seconds, or call modifyAckDeadline to extend it dynamically during processing.
Pub/Sub has a maximum message size of 10 MB. For larger payloads, the best practice is to upload the file to Cloud Storage and send a reference (the file URL) as the message. The subscriber then downloads the file from Cloud Storage.
Use IAM roles to control who can publish to a topic and who can subscribe. Use service accounts for applications. Encrypt messages in transit with HTTPS and at rest by default. You can also use customer-managed encryption keys (CMEK) for additional control.
A dead letter topic is a separate topic where messages are moved after they fail to be processed a configurable number of times. This prevents a single bad message from blocking the subscription. You can later inspect and reprocess those messages.
You've finished Pub/Sub and Event-Driven Integration. Continue through the PCD study guide to build a complete picture of the exam.
Done with this chapter?