[MUSIC PLAYING]
MARTIN OMANDER: Hi, Tianzi.
TIANZI CAI: Hi, Martin.
Good to see you again.
MARTIN OMANDER: You, too.
I want to ask your help in answering
a few more questions for me and other developers
about Pub/Sub ordering today.
TIANZI CAI: Of course, I'm happy to help.
Let's get on with them.
[MUSIC PLAYING]
MARTIN OMANDER: So Tianzi, in the last episode,
you introduced ordering of Pub/Sub of messages
in the ride-hailing app I was building.
In my original implementation, if a user requested a ride
and then canceled that ride, sometimes, the cancellation
would arrive before the initial ride request,
which confused my application.
TIANZI CAI: Ah, yes, I remember that.
You enabled a message ordering to resolve this issue.
MARTIN OMANDER: Yeah, you showed me
how to do that so that all messages for a particular rider
arrive in the order they are published.
In other words, the ordering key is the rider ID.
Here is my code for that, and here's
my Pub/Sub subscription in the Cloud Console,
with the Ordering box checked.
TIANZI CAI: Very nice, we can refer back
to your code and your configuration
as we answer the questions.
MARTIN OMANDER: Excellent, so the first question
is from Jacob on Stack Overflow, specifically about the push
subscription case.
Jacob writes, "does cloud Pub/Sub message ordering
mean the subsequent message is not
delivered until the previous one is acknowledged?"
TIANZI CAI: That is correct.
To use an example from the ride-hailing app,
if the request ride message by Bobcat
is published before the cancel ride message by Bobcat,
the request ride message must be acknowledged
by your application before Pub/Sub even delivers
the cancel ride message.
MARTIN OMANDER: Oh, so does that mean
that I can create a bottleneck if my code doesn't acknowledge
messages?
TIANZI CAI: That is likely for Bobcat,
but it won't affect other rider IDs.
For instance, this won't affect request and cancel
ride messages from Starfish.
To avoid blocking subsequent messages
from individual riders, your code
should always acknowledge messages.
If the message is badly formatted
or if a code throws an exception,
catch that exception, acknowledge the message,
and report the error to the operator.
Don't fail to acknowledge an ordered message
for an extended period of time.
MARTIN OMANDER: So the second question is from Robin Thomas,
in a comment for our previous video.
"What's the behavior when the publisher sets message ordering
and publishes messages with an ordering key
and there are multiple subscribers listening
to the same topic, but only one of them
is interested in ordered messages?"
TIANZI CAI: That is a great question.
I think there are two parts to it.
For serverless and push, it's easy.
You have only one push URL per subscription.
For example, in your ride-hailing app,
the subscriber is your service, built in Cloud Run.
Outside serverless, however, pull
subscriptions are more common.
When multiple subscribers, like multiple Compute Engine
instances, are pulling from the same topic,
messages of the same ordering key
are delivered to the same subscriber.
You may hear this described as the affinity guarantee
of Pub/Sub-ordered delivery.
MARTIN OMANDER: OK, so what if I have multiple subscribers
pulling from a subscription, and only one of them
is interested in ordered messages?
TIANZI CAI: Subscribers actually don't
control what kind of messages to get, ordered or unordered.
Instead, this is determined by the subscription.
If the goal is to separate unordered messages
from ordered messages, it's probably best
to publish them to different topics.
In your ride-hailing app, it would be a good idea
to publish ordered messages, like request ride
and cancel ride messages, to a rider's topic and unordered
messages, like when a user updates their password,
to a different topic.
MARTIN OMANDER: All right, so I think
what this means, to me, for my ride-hailing app,
is that, one, if I use push subscriptions
and a serverless subscriber, like Cloud Run,
I don't have to worry about multiple subscribers,
and, two, it makes things easier if I publish
ordered and unordered messages to different topics.
TIANZI CAI: You got it.
MARTIN OMANDER: All right, very good.
So now, the third question.
Yesterday, in my ride-hailing app,
I noticed that I got an exception when
trying to publish a message.
After that, no more messages for that rider ID, that
ordering key, were published, so how
should my code deal with publishing exceptions?
And this happened when I was moving topics around
and changing permissions.
TIANZI CAI: I'm glad you asked about it because there
is something special here.
Most publishing failures are retried automatically,
but in a case of non-retriable errors, for example,
if the topic has been deleted and you're using ordering,
you shall call out resume publish
to restart published messages of the affected ordering keys.
You can add this code to resume the publisher
in a try-catch block.
MARTIN OMANDER: Hmm, excellent, Tianzi, now,
for the fourth and final question,
my system has one Cloud Run service
running in Europe and another running in the US.
And both publish ordered Pub/Sub messages to the same topic.
Will ordering still work?
TIANZI CAI: Yes, if you specify the same regional endpoint
when you create the publishers, you
can look up the list of available regions here
and pick one from the list.
MARTIN OMANDER: Oh, so if I use this code
with this regional endpoint, all messages
will be published in Europe, even if this code actually
runs in the US?
TIANZI CAI: That's right.
MARTIN OMANDER: Great, thank you, Tianzi.
I think my ride-hailing app will work much better
after I implement these tips you've shown me.
TIANZI CAI: That's wonderful to hear.
Getting ordering right is useful, and I'm glad to help.
MARTIN OMANDER: If you have any questions for Tianzi or me,
please leave them in the comments below.
Also, let us know if there are other serverless topics you'd
like to see in our videos.
Until next time.
[MUSIC PLAYING]