Understanding Google Cloud Pub/Sub and How It Works

Before you start reading this article, please check out my previous article Google Cloud Pub/Sub Overview to understand the event-driven microservice architecture with and without Cloud Pub/Sub with the real-time use case of the Shoe Mart application.

Cloud Pub/Sub

The Cloud Pub/Sub supports the publish-subscribe pattern, and the way Cloud Pub/Sub works is described below.

1. The publisher application sends a message to the topic, which is a named resource.
2. The messages are stored in the message storage until acknowledged by all subscribers.
3. To receive these messages, the subscriber creates a subscription to the topic.
4. The subscriber receives the message by either Cloud Pub/Sub pushing them to the subscriber chosen endpoint or by the subscriber pulling them from the service.
5. The subscriber sends a message acknowledgment to the Pub/Sub subscription, the message is removed from the subscription backlog and not delivered again.
6. The message itself contains payload content and payload attributes that describe the payload content.

Applications/Services Communication Types

There are three different ways our applications/services can communicate with the Google Cloud Pub/Sub. They are given below in detailed information.

One to Many

Publisher will create and send messages to the topic and more than one subscriber will receive those messages.

Example

The publisher will create and send messages to Topic A, and subscribers B and C receive those messages from Topic A through Subscription AB and Subscription AC.

Many to One

Many publishers will create and send messages to the topic and only one subscriber will receive those messages.

Example

Publishers A and B will create and send messages to Topic A and Topic B, and Subscriber X will receive those messages through Subscriptions XA and XB.

Many to Many

Numerous publishers will create and send messages to the topic, and many subscribers will receive those messages.

Shoe Mart Services Communication in Cloud Pub/Sub

We saw the Shoe Mart microservices architecture with Google Cloud Pub/Sub in the last article. Now, I will explain how our services will publish messages to the topic and how subscribers will receive those messages through subscription in our architecture.

The above picture represents the Shoe Mart microservice architecture with Google Cloud Pub/Sub on the last article. Here are the step-by-step details of how our services are publishing messages to the topic and how our services are receiving those messages from the topic through subscriptions.

Step #1

In the below picture, the Order Service will create and send messages to Pub/Sub, and the Package and Notification services will receive messages through subscription by using a push-pull operation.

Order Service sends messages to the Topic, which is named Order. The Package Service Subscriber and Notification Service Subscriber receive messages from the Topic Order through the Order-Packaging and Order-Notification subscriptions. 

Step #2

Package Service sends messages to the Topic, which is named Package. The Shipping Service Subscriber and Notification Service Subscriber receive messages from the Topic Package through the Package-Shipping and Package-Notification subscriptions.

Step #3

In the below picture, Shipping Service will create and send messages to Pub/Sub, and the Order and Notification services will receive messages through subscription by using a push-pull operation.

Shipping Service sends messages to the Topic, which is named Shipping. The Order Service Subscriber and Notification Service Subscriber receive messages from the Topic Shipping through the Shipping-Order and Shipping-Notification subscriptions.

Global Availability

Assume the Shoe Mart company wants to expand business globally and is considering a packaging service in the US and a shipping service in Europe. There are no worries because Cloud Pub/Sub is a global service, and it ensures getting messages from one location to another location with consistent latency and no service replication required. The Shoe Mart team can focus on developing the services and can leave the global scaling to the Cloud Pub/Sub. 

Publish-Subscribe Endpoints

The publisher can be any application that makes the HTTPS requests to Google APIs.com, including App Engine, Compute Engine, Kubernetes Engine, Web Browser, and mobile/third party devices/app.

Pull subscribers also can be any application that makes the HTTPS requests to Google APIs.com to pull the messages from the Pub/Sub through subscriptions.

Push subscriber should be a webhook endpoint that accepts the POST HTTPS requests.

Thanks for reading this article, and if you have any questions, please reach out to me through email at talk2amareswaran@gmail.com.

Happy architecture! Happy coding!