PRIYANKA VERGADIA: A subscription
can use either the Push or a Pull mechanism
for message delivery.
But which one makes sense for your application?
Stay tuned to find out.
[MUSIC PLAYING]
Welcome to "Pub/Sub Made Easy."
I am Priyanka, and in today's episode,
we will learn to pick the right delivery mechanism
for our Pub/Sub messages.
In the last episode, we learned that in Pull delivery,
Subscriber application initiates the request to the Cloud
Pub/Sub to receive messages, while in Push delivery,
Cloud Pub/Sub initiates the request to the Subscriber
application to deliver messages.
How do we choose between Push and Pull
mechanism for our use cases?
Well, let's look at this step by step
by comparing a few properties.
What kind of endpoints are needed for Push versus Pull?
Well, in Pull mechanism, because the subscriber is pulling
messages from Cloud Pub/Sub via the API,
any device on the internet that has authorized credentials
to call the API can serve as a Pull endpoint.
In case of Push mechanism, the message
is being pushed by Cloud Pub/Sub to the subscriber endpoint,
so the endpoint must be reachable via DNS name,
and have SSL certificate installed.
It should be a non-self-signed certificate.
The benefit of Push subscriptions
is that they are largely decoupled from the Pub/Sub.
They don't need to have credentials or use the Pub/Sub
client library.
They just need a bit of application logic
that knows how to parse Pub/Sub host request body.
It's a very lightweight integration model.
How do you balance load while using Push versus Pull?
Well, in Pull mechanism, multiple subscribers
can make Pull calls to the same shared subscription.
Each subscriber will receive a subset of the messages.
While in Push mechanism, the Push
endpoint itself can be a load balancer distributing
the request to the right back end.
The real use case for this Push model is front end,
multiple subscriptions pointed to the same endpoint.
So as you add new topics, you don't have to change anything
about your subscriber.
How do you control the flow of messages
received by the subscriber?
What if the subscriber cannot handle the messages fast
enough?
Well, in Pull mechanism, the subscriber client
controls the rate of delivery-- because, you know,
it's the one pulling those messages.
The subscriber can dynamically modify
the acknowledgment deadline, allowing message processing
to be arbitrarily long.
While in Push scenarios, the Cloud Pub/Sub server
automatically implements the flow control
by backing off exponentially whenever
the endpoint returns error, or takes a long time to respond.
There's no need to handle message flows at the client
side.
Although the client can indicate that it cannot handle
the current message load by passing back an HTTP error.
When it comes to efficiency and throughput,
Pull mechanism achieves high throughput
per CPU and bandwidth by allowing batch delivery
processing and acknowledgments.
The downside is that you must always
have an application running to keep getting messages
from Pub/Sub.
With Push delivery, you can take advantage of the scale
to zero serverless pattern supported by Cloud Functions,
Cloud Run, or App Engine.
This is useful when your request rate is low or very uneven.
The Push mechanism delivers one message per request,
and limits the maximum number of outstanding messages.
Now, to the most important question--
which mechanism is best for your application?
Well, here goes.
You would typically set up Pull subscribers
if the volume of messages is large--
like, many more than 1 per second.
If efficiency and throughput of message processing is critical,
and if public HTTPS endpoint with non-self-signed SSL
certificate is not feasible to setup.
And it's recommended to use Push subscribers
if there are multiple topics that must be processed
by the same webhook, with App Engine standard and Cloud
Function subscribers, and if you use an environment where
Google Cloud Platform dependencies,
such as credentials and client libraries,
are not feasible to set up.
All right, so today we learned how
to choose between Push and Pull subscription models.
We compared the set for endpoint, load balancing,
efficiency, and flow control for Push and Pull subscribers.
These are factors that play a role
in finally deciding which model to choose
in your specific scenario.
Join us next time to learn more about setting up the subscriber
to receive messages using Pull delivery.
If you like this video and would like to see more such content,
don't forget to Like and subscribe to our channel.