Does the Existence of Message Brokers Render Webhooks Irrelevant?

While both webhooks and message brokers can handle event-driven situations, they have different use cases and can often complement each other in a system. TL;DR they are both very relevant indeed. Question answered. Now you can stop reading... or not.

Does the Existence of Message Brokers Render Webhooks Irrelevant?
Tremendously bad use of operators

Now this started as a random pub conversation and somehow found itself here. Don't blame me, I didn't want to do it, it just happened. Here we go...

While both webhooks and message brokers can handle event-driven situations, they have different use cases and can often complement each other in a system. TL;DR they are both very relevant indeed. Question answered. Now you can stop reading... or not.

ユースケース

Webhooks are often used for real-time, synchronous operations where an immediate response or action is expected. For example, when an event happens in a system, the webhook can instantly notify another system about it.

Message brokers, on the other hand, are generally used for asynchronous operations where there's no immediate response expected. They're typically used when you want to ensure that a message is delivered even if the receiving system is temporarily unavailable.

デザイン哲学

Webhooks use a push model, while message brokers use a pub-sub or queue model. In a push model, the sender pushes the data to the receiver as soon as it's available.

In a pub-sub or queue model, the sender publishes a message, and it's up to the subscribers or the receivers to pick up the message when they can.

アプリケーション統合

Webhooks are typically easier to integrate with other applications because they use the standard HTTP protocol and often don't require any special libraries.

Message brokers may require specific libraries to interact with them.

確実

In general, webhooks don't guarantee delivery. If the receiving system is down or can't be reached for some reason, the webhook may be lost. Some systems may automatically retry sending a webhook a certain number of times, but this isn't a universal feature of all webhook implementations.

Message brokers generally offer a higher level of reliability and fault tolerance. If a receiver is not ready to handle a message, the message broker can store the message and ensure its delivery when the receiver is ready.

複雑さとオーバーヘッド

Message brokers can add complexity and overhead to the system because they have to manage the storage and delivery of messages.

Webhooks, on the other hand, are simpler and don't require any storage... or do they? In terms of improving reliability they may require some storage for a retry mechanism or to reduce dataloss if the webhook dies before the entire request chain has been completed. Or something like that. Anyway.

エピローグ

In many systems, you might find that webhooks and message brokers are used together. For example, a webhook could trigger an event that sends a message to a message broker. Then, the message broker ensures the delivery of the message to all interested parties. In other systems, you might use only one or the other, depending on the specific requirements of the system. Blah blah blah.