Uses Cases - Google's Cloud Pub/Sub.

For example, you could queue up a large number of tasks in a Pub/Sub topic and have them distribute it amongst multiple workers, such as Compute Engine instances. Each instance can grab a task in turn from its subscription. New tasks can be queued up, waiting for available capacity.

When you need to control the order of events in a loosely coupled system.
For example, an order processing system could place an order in a topic which could then be consumed by a worker system, perhaps invoicing, before passing it into a queue for the next system to consume, perhaps packaging and posting.

For example, you have a system that sets up new users when they register with your service.
A registration could publish a message and your system could be notified to set the user up.

Rather than pushing logs to a single source, they could be sent to a Pub/Sub topic to be consumed by multiple subscribers, such as a monitoring system and an analytics database for later querying.

Hundreds, thousands, even hundreds of thousands of internet-connected devices can stream their data or telemetry into Pub/Sub topics to be consumed on-demand by your analytic streams or even transformed through Dataflow first.

Often, you'll see Pub/Sub used as the glue that adds logic and joins lots of other services together

in a topology of GCP services.

Depending on the workflow we need to achieve, patterns in Pub/Sub messaging

You just create a message containing your data, this is going to be a JSON payload, that's base64 encoded.
The total size of the payload needs to be 10MB or less.
Then you send the payload as a request to the Pub/Sub API specifying the topic to which the message should be published.

You simply create a subscription to a topic.
Subscriptions are always associated with a single topic.
There are 2 types of delivery method for subscriptions.
Pull is the default method.
When you have created a pull subscription, you can make ad hoc pull requests to the Pub/Sub API, specifying your subscription to receive messages associated to that subscription.
When you receive a message, note that you have to acknowledge that you've received it.
If you don't, that message will remain at the top of the queue associated with your subscription, and you won't get the next message, or any messages after that, until you've acknowledged it.
Alternatively, you can configure a push subscription, which will automatically send new messages to an endpoint that you define.
The endpoint must use the HTTPS protocol with a valid SSL certificate. And of course, something has to sit on the end of that endpoint that is capable of receiving and processing a message.

Knowledge Sharing