From the HR analogy previously, we saw how Pub/Sub works and it's used in decoupling systems. Let's now discuss the technical details associated. We'll start by understanding the distribution of messages and different patterns. Note that the different colors for messages represent different messages. The first pattern is just a basic straight through flow, where one publisher publishes messages into a topic, which then get consumed by the one subscriber through the one subscription. The second pattern is fan in or load balancing. Multiple of publishers can publish the same topic, and multiple subscribers can pull from the same subscription, leveraging parallel processing. What you see here are two different publishers sending three different messages all on the same topic. That means the subscription will get all three messages. The third pattern is fan out, where you have many use cases for the same piece of data, and all data is sent to many different subscribers. As you can see here, we have two subscriptions. So both are going to get the messages, both the red message and the blue message. In the HR example we saw, the same new hire event was used by multiple subscriber applications. Now that you are familiar with publish and subscribe patterns, let's see how subscribers get the messages delivered through subscription. Cloud Pub/Sub subscription allows for both push and pull delivery. In the pull model, your clients are subscribers and will be periodically calling for messages, and Pub/Sub will just be delivering the messages since the last call. In the pull model, you have to acknowledge the message as a separate step. So what you see here is we initially make the call to the subscribers, it pulls the messages, it gets a message back, and then separately it acknowledges that message. The reason for this is because the pull queues are often used to implement some kind of queuing system for work to be done. So you don't want to acknowledge the message until you firmly have the message and have done the processing on it. Otherwise, you might lose the message if the system goes down. Therefore, we generally recommend you wait to acknowledge until after you have received it. In the pull model, the messages are stored for up to seven days. In push delivery, Cloud Pub/Sub initiates requests your subscriber application, to deliver messages. The Cloud Pub/Sub servers sends each message as an HTTPS request to the subscriber application at a preconfigured endpoint. In the push scenario, you just respond with status 200 Okay for the HTTP call, and that tells Pub/Sub the message delivery was successful. Push delivery is ideal when multiple topics must be processed by the same webhook for example. The way the acknowledgments work is to ensure every message gets delivered at least once. What happens is when you acknowledge a message, you acknowledge on a per subscription basis. So if you have two subscriptions, say you have one acknowledged and the other one not acknowledged. Then the one that was acknowledged will continue to get subsequent messages while Pub/Sub will continue to try to redeliver the unacknowledged message up to seven days to the other one until it is acknowledged. Now there is a replay mechanism as well that you can rewind and go back in time and have it replay messages, but in any case, you will always be able to go back seven days. You can also set the acknowledgment deadline and do that on a per subscription basis. So if you know that on average it takes you 15 seconds to process a message in your work queue, then you might set your acknowledgment deadline to 20 seconds, this will ensure it doesn't try to redeliver the messages. Subscribers can work as an individual or as a group. If we have just one subscriber, it is going to get every message delivered through that subscription. However, you can set up worker pools by having multiple subscribers sharing the subscription. In the case of a push subscription, you only have one web endpoint. So you will only have one subscriber typically. But that one subscriber could be a Standard App or a Cloud Run Container Image which autoscales. So it is one web endpoint but it can have autoscale workers behind the scenes, and that's typically a pretty good pattern.
