Hey, I’m evaluating a move from HTTP webhooks to either Google Pub/Sub or Amazon EventBridge + SQS for my app. Since I’m not locked into any particular cloud ecosystem and will just be pulling messages from workers without deep service integration, I’m trying to figure out which makes more sense.
The Shopify documentation is pretty vague on this topic, basically just stating:
Shopify recommends using Google Pub/Sub as a cloud-based solution for delivering webhooks. You can also use Amazon EventBridge
We’ve used gcp pub/sub previously and it was great. I’m not sure what your pull system would look like.
I’d question the benefits of doing pub/sub system → sqs → pull integration, over just a regular HTTP webhook. i.e, does the complexity actually make things ‘less’ reliable? (probably not!).
I’d be interested in hearing a bit more about the motivation for migrating from http → pub/sub/event bus
Hey Sammy! Right now with regular HTTP, webhooks hit our server and we queue them up for our worker to process later.
This creates a few potential failure points: if our server goes down, we lose webhooks entirely. Sure, Shopify will retry them, but they do it on their own schedule with exponential backoff - so events can arrive completely out of order. An event from 2:00 PM might not get successfully delivered until 2:30 PM, showing up after events that happened at 2:15 PM.
Switching to GCP Pub/Sub or AWS EventBridge + SQS takes that pressure off our web server completely. We don’t need to maintain our own queue system anymore - just have a background worker that processes webhooks at its own pace.
If our app goes down, we don’t lose any webhooks, and when we come back online, our worker processes them in their original chronological order - not in whatever scrambled sequence Shopify’s retries delivered them. No more out-of-order event headaches during outages
If you aren’t already in the GCP or AWS environment, I’d lean toward PubSub. EventBridge has additional complexity compared to PubSub, as you also need to incorporate SQS. There are several steps involved, and more things that can go wrong / be misconfigured.
One thing to watch out for with Pub/Sub push:
It doesn’t handle backpressure well. During webhook bursts, Pub/Sub keeps increasing delivery until your server starts failing. Then it backs off too much and takes minutes to recover. We’ve seen this cause real downtime and delayed processing.
The real issue isn’t transport however. It’s everything after: rate limits, retries, queueing, deduplication, dead-letter queues, and visibility.
That’s what Hookdeck (I’m the founder) is built for. We act as a webhook layer in front of your app. You don’t have to change your infrastructure or do any rewrite.
We queue and throttle incoming Shopify webhooks
Deliver to your existing endpoint at a pace your system can handle
Give you control over retries, filtering, and transforms
Provide full searchable webhook history, logs & metrics.
If you’re building on Shopify and don’t want to worry about webhook infrastructure, Hookdeck’s probably worth a look. Feel free to reach out if you’re stuck or want to talk through it.
