Webhook vs PubSub
A webhook delivers an event as an HTTP POST to one endpoint the sender already knows about. Pub/sub publishes the event to a topic, and a broker copies it to every subscriber, none of which the publisher needs to know. Webhooks fit delivery across a trust boundary to someone else's server; pub/sub fits fan-out inside infrastructure you control.
Both are ways of moving events in an event-driven architecture, and the differences that matter come down to who chooses the recipients and who runs the machinery in between.
How webhooks deliver an event
A webhook is a way for a web application to provide other applications with real-time information. When a specific event occurs on the web application, it sends a message to a specified URL (known as a "webhook endpoint"). The other application can then receive the message and take appropriate action, such as sending a notification or updating its own data.
Webhooks are often used in scenarios where a web application needs to send data to another application in real-time. For example, a payment processing company might use webhooks to notify a merchant's website every time a customer completes a payment. The merchant's website can then update its records and display the latest information to the customer.
How pub/sub delivers an event
PubSub, short for "Publish/Subscribe," is a messaging pattern that allows applications to communicate with each other without having to know about each other's existence. In a PubSub system, publishers send messages to a topic, and subscribers receive messages from that topic. The PubSub system acts as a message broker, routing messages from publishers to subscribers without the two needing to be directly connected.
PubSub is often used in scenarios where multiple applications need to receive and process messages, but the publisher and subscribers are not known to each other. For example, a news website might use PubSub to send updates to multiple third-party applications, such as a weather app, a stock market app, and a sports app. Each of these applications can subscribe to the news website's topic and receive the updates in real-time.
Who controls delivery
One key difference between webhooks and PubSub is the level of control they provide over the message delivery. With webhooks, the publisher has complete control over who receives the message and when it is delivered. The publisher specifies the webhook endpoint, and the message is delivered directly to that endpoint. In contrast, with PubSub, the publisher has no control over who receives the message. The message is delivered to all subscribers of the topic, regardless of whether the publisher knows about them or not.
Given this difference in control, PubSub may be more suitable for use in an internal system where the messages are being sent and handled globally and the listeners are trusted. In this case, the lack of control over who receives the message may not be an issue, as the listeners are part of the same system and can be trusted to handle the message appropriately.
On the other hand, webhooks may be more suitable for use in external-facing applications, where it is important to have more control over who receives the message and when it is delivered. This could be important, for example, if the publisher is sending sensitive data and wants to ensure that it is only delivered to a specific endpoint. Additionally, webhooks may be preferred if the publisher wants to have more control over the timing of the message delivery, as they can specify when the message is sent to the webhook endpoint.
Choosing between webhooks and pub/sub
Pick by where the recipient sits. If the recipient is another company's server, use webhooks: you address it explicitly, and the sender owns signing, retries, and a delivery log because the receiver may be down and there is nobody to call. If the recipients are your own services, use pub/sub and let the broker handle subscriptions and redelivery, which is also how you avoid running one HTTP client per consumer.
The two also combine. A common shape is a topic inside your system that a delivery service subscribes to, which then fans the event out to every customer endpoint subscribed to that event type, the pattern described in webhook fan-out. For the adjacent comparisons, see webhooks vs message queues and Kafka vs Pub/Sub.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis