If you have ever used the Cloud Academy Android application, you should be aware that you have the option to subscribe to our platform by paying through Google Pay. We offered this option because most mobile users nowadays prefer paying with integrated payment systems offered by both Android and iOS.
The Challenge
Because of this integration in the Cloud Academy mobile application, we needed to think about implementation to support Google Subscriptions.
We reached the Google doc and learned that for every subscription action, such as a subscription creation or a renewal, we would receive a notification generated by the Google Pay service. Google sends all notifications to a Google Cloud Pub/Sub topic which we needed to specify.
So the challenge was: How can we handle loads of subscription notifications in an efficient, reliable, and fault-tolerant way?
Google Cloud Pub/Sub
Luckily for us, all the Google Pay notifications are sent to a Google Cloud Pub/Sub topic that we can access to reach them.
Before going through the solution that we implemented, I want to give you a high-level overview of what Pub/Sub is. Google Cloud Pub/Sub is a messaging-oriented middleware that lets you decouple services that create messages (the Publishers) from services that process messages (the Subscribers).
The core components in a Pub/Sub solution are the following:
- Topics: An entry point for the publishers that want to publish messages.
- Subscriptions: An entity associated with a specific topic and that is used by the subscribers to receive messages published on the topic the subscription is associated with.
There are two kinds of subscriptions.
Pull Subscriptions
A pull subscription is used when the subscriber wants to manually get all the messages that have been published on the topic the subscription is associated with. In this case, the subscriber makes a pull call, receives the messages, and then sends an ACK (acknowledge) to let Pub/Sub know that everything has completed correctly.
Push Subscriptions
A push subscription is used when the subscriber wants to be automatically triggered when a new message is published on the topic the subscription is associated with. In this case, Pub/Sub directly sends each new message to the subscriber and it needs to send an ACK (acknowledge).
The Solution
To build a solution that meets the requirements described below, we set up a single Pub/Sub Topic and then we created and attached a Push Subscription to it. We set Google Pay to send Google notifications to our Pub/Sub topic, which completes the Publisher part of our infrastructure.
That was a good start, but we still needed to set up the Subscriber part of the infrastructure. For this purpose, we created a webhook into our software infrastructure and set it as the target of the push subscription. This way, all the messages published to the topic are captured and then sent to our internal webhook.
Security and Reliability Issues
Because our internal software needs to authenticate any request made by external entities, we needed to find a way to authenticate all the requests made to the webhook. With this approach, we could be sure of which requests were allowed (all those made from Google Pub/Sub) and which were not allowed (such as malicious requests). Luckily, we were able to set up authentication on the Pub/Sub Subscription. So, each message sent to the webhook is signed with a JWT that is inserted in the header, and we are able to verify it with an authentication middleware we have in our software.
Another very important point to think about was the reliability of our solution. Suppose that for an unexpected error, when Pub/Sub sends the message to the webhook, it is not able to process the message and raises an error (5xx error code). We couldn’t lose messages for any reason. Google Pub/Sub helped us again. Luckily, we were able to set up the Push Subscription to not delete messages until an ACK was sent, and to retain them for a 72-hour period. During this period, Google would have tried to send the message again until the process succeeded.
