MARTIN OMANDER: Hi, Dina.
What are you doing?
[ALARM RINGS]
DINA PORTMAN: Well, the last time
we talked, we helped Katie at CatTube use webhooks
to set up a system for processing GitHub issues.
I'm worried the functions may not
complete before they time out, or there might be an error
and the whole thing will fail.
MARTIN OMANDER: I think we have just the thing
to help Katie improve her webhook.
[MUSIC PLAYING]
DINA PORTMAN: Katie's webhook is currently
set up to create notifications, trigger an action,
and stream data into BigQuery.
MARTIN OMANDER: That's a lot for one webhook.
DINA PORTMAN: You're right.
Her current system works, but it's fragile.
Everything is tangled together and running synchronously.
This means we're not returning a response to GitHub until all
the functions have completed.
MARTIN OMANDER: That's risky business,
given that each of these services
are constrained by timeouts.
Cloud Run has a 15-minute timeout,
but GitHub wants a valid response
within 10 seconds of its request.
Katie's request must be completed by the shorter
of these two timeouts.
DINA PORTMAN: Katie will probably
be able to complete all three functions in under 10 seconds.
But I wouldn't want to rely on "probably."
Luckily, we can use pub/sub to asynchronously handle
the events from the GitHub API.
Katie creates a new Cloud Run endpoint
to be the initial webhook target.
This new endpoint will verify the signature,
publish the message to pub/sub, and quickly return
a 200 OK status message to GitHub, thus allowing
the rest of the work to be processed asynchronously.
MARTIN OMANDER: But once you send
the message to pub/sub, how do you trigger those functions?
DINA PORTMAN: Well, we need to create another service
and have it subscribed to the pub/sub topic.
This way, it'll be triggered whenever a message is
posted to the topic.
For additional security, when we create the service,
we should allow only authorized requests
and set up pub/sub to send us authorization tokens.
Here, we can look at our reconfigured Slack function.
It's confirming that the data it receives
looks like a pub/sub message, and then triggers
the notification to Slack.
Thanks to our setup, we don't have
to worry about authorization or signature verification.
Our architecture looks a little more complicated now,
but we've solved our issue with the timeouts.
And as an added bonus, this kind of decoupling
creates a system that is better able to handle errors.
MARTIN OMANDER: What do you mean, Dina?
DINA PORTMAN: Well, by creating separate services for our three
different functions, we ensure that if one service has
an error the other two are not affected.
This is one of the benefits of a microservice architecture.
MARTIN OMANDER: That's great.
But what do we do about the errors in the broken service?
DINA PORTMAN: If the message is not successfully delivered,
pub/sub will keep retrying until it succeeds.
Once we have the service back online,
the messages will be processed through our healthy service.
MARTIN OMANDER: So before, Katie's webhook target worked,
but it was synchronously triggering
three distinct functions.
Meaning it was at risk for timeouts,
and for one error in one function
taking down the whole service.
DINA PORTMAN: That's right.
But now that Katie has rewritten her webhook
to send all events through pub/sub,
she has a more robust and fault-tolerant webhook target
ready to take on the world.
MARTIN OMANDER: Thanks to pub/sub
and a microservice architecture, Katie
can rest assured that her team isn't missing any notifications
or losing any data.
[MUSIC PLAYING]