C#•4w ago

Webhook vs queue for updates notifications

I have an entity I am responsible for and there is a requirement to let other apps in the organization know whenever an update occurred.
It is required that each update is delivered to the other apps even if they are offline currently (no message drop tolerance).
The amount of apps is around 6 and the frequency of updates is around 50 to 100 updates a day (totally).
Each app should be able to listen to specific entities updates that are relevant to it.

One option is using a queue (say rabbit) and publish an update message that anyone can listen to.
Another option is using a webhook so each app can subscribe to changes on specific entities.

What's the preferred solution or are there other ways this should be done? Is there a best practice here?

Joschi•11/28/25, 2:34 PM

I'm not really familiar with RabbitMQ.
But I can see some complexities with webhooks and no message dropped.

Because now you need to keep track of a lot of things.

What to send to which service.
You need to take care or allow for configuration of the routing to them (urls/ips whatever).
And you need to track which message was acknowledged.

You then need to find a mechanism for resending dropped messages as soon as the service is back online. (That's harder if the order in which the messages are sent is relevant)

Those are all solvable problems for sure. But put a lot of responsibility on your side of things.

While allowing other services to pull information from you or some queue makes the services handle all this.

JJoschi I'm not really familiar with RabbitMQ. But I can see some complexities with web...

AllMightOP•11/28/25, 2:39 PM

But I have two concerns:

Opening a public message queue seems like a bad practice
Polling is problematic as they don't know when an update happened

I guess polling is easiest for me but public queue is easier too?

Angius•11/28/25, 2:43 PM

If those are 3rd party apps connecting and you don't want to open the queue to them, webhooks are the way to go

Angius•11/28/25, 2:44 PM

With some retry policy of course

AllMightOP•11/28/25, 3:25 PM

@ZZZZZZZZZZZZZZZZZZZZZZZZZ hmm one thing I am not sure with webhooks is how to architect it.
Option 1: directly call the webhooks when updating (easy but fragile)
Option 2: use internal rabbitmq or similar and a different service that reads from queue and calls webhooks

AllMightOP•11/28/25, 3:26 PM

What's the best practice here? Does it matter how many apps are subscribed and how many updates I expect? As both are not much currently as noted above

Angius•11/28/25, 3:31 PM

Calling webhooks on update means you can't really easily retry the call if it fails

Angius•11/28/25, 3:31 PM

So you'd need to at least run the webhook calls in some background task, maybe with Polly or something

Angius•11/28/25, 3:31 PM

And end the task only when all calls have returned 200 OK

AAngius So you'd need to at least run the webhook calls in some background task, maybe w...

AllMightOP•11/28/25, 3:45 PM

True... So I wonder if a queue is a good solution here to also avoid delaying the actual update operation until all webhooks are updated

AllMightOP•11/28/25, 3:45 PM

Or maybe some other way

Angius•11/28/25, 3:45 PM

Yeah, it might be a good idea

AAngius Yeah, it might be a good idea

AllMightOP•11/28/25, 3:57 PM

Worth the complexity? Or anyway necessary?

Angius•11/28/25, 3:58 PM

Well, another way would be to spawn background tasks yourself, which might end up actually more complex

AAngius Well, another way would be to spawn background tasks yourself, which might end u...

AllMightOP•11/28/25, 4:27 PM

So to summarize:

I need to create endpoints for handling subscriptions to webhook (and insert to DB)
I need to publish an event to the queue on update (what happens if the update succeeds but the queue operation fails?)
I need a consumer for events (general different service?) the reads webhooks from DB (shared DB here?) and fans out the webhook subscribers to another queue
Another consumer for webhook notifications (general different service?) that actually calls the single webhook
I still need to somehow handle failures and retry with quartz? hangfire? polly? something else? Where should that logic sit?

Anyway it is also a question of how many services should I create - one that handles everything or split to 2 or 3 services... Splitting allows better scaling but I am not sure if I need that scaling right now

Seems complicated to be honest so also what should I remove and what should stay?

Angius•11/28/25, 4:31 PM

I wouldn't necessarily use multiple queues tbh

Angius•11/28/25, 4:32 PM

Just one queue you push an event like "created new blogpost" to

AllMightOP•11/28/25, 4:32 PM

Also maybe kafka should be used here instead of rabbit as it can save messages in case some part is down

Angius•11/28/25, 4:33 PM

And a service that gets triggered on that event, grabs the URLs it needs to send the webhook to from the db, and sends it with retries with Polly or something

Angius•11/28/25, 4:33 PM

Don't have much experience with Kafka, so I won't help with that choice I'm afraid

Angius•11/28/25, 4:33 PM

Two queues could be useful if you had, like, 300 webhooks

Angius•11/28/25, 4:33 PM

You have, what, 6?

Angius•11/28/25, 4:33 PM

So one queue is enough

AAngius And a service that gets triggered on that event, grabs the URLs it needs to send...

AllMightOP•11/28/25, 4:35 PM

I see but there are some questions left:

should the consumer be a different service that accesses the same DB? They have a shared subscriptions table
Should the webhook calls be parallel?
Retries are problematic if the service shuts down... do I need some DB table to handle retries? How would you approach that considering I can't lose any messages in between

AllMightOP•11/28/25, 4:37 PM

How to make the update and queue writing atomic if possible or needed (I mean queue publish for some reason fails but update happened)

Angius•11/28/25, 4:37 PM

A hosted service or some such, yeah. I wouldn't spin up another project for it
I'd say so, yeah
Keep track of it in a database

AllMightOP•11/28/25, 4:38 PM

For 3 is polly handling it automatically?

Angius•11/28/25, 4:38 PM

I don't think so, no

Angius•11/28/25, 4:39 PM

Or you could have one event on the queue per webhook, then remove them from the queue only on success

Angius•11/28/25, 4:39 PM

That way, even on restart, you will have the unsent webhooks on the queue

Angius•11/28/25, 4:39 PM

Regarding 4, I'm not sure, never considered the queue write to be able to fail lol

AllMightOP•11/28/25, 4:40 PM

Can I trust rabbit for storing the event? Also I haven't thought about it yet but what if another update came in before the previous update was handled?

AllMightOP•11/28/25, 4:41 PM

Or maybe it is acceptable for two updates to result in two consecutive webhook calls

AAngius Or you could have one event on the queue per webhook, then remove them from the ...

AllMightOP•11/28/25, 5:28 PM

Safe to assume rabbit saves events forever?

AllMightOP•11/28/25, 5:29 PM

And also how to handle two updates one after the other

Angius•11/28/25, 5:41 PM

Not sure about Rabbit

Angius•11/28/25, 5:41 PM

But if two events occur one after another, send a webhook for both

Angius•11/28/25, 5:42 PM

I wouldn't bother batching them or anything

AllMightOP•11/28/25, 5:56 PM

@ZZZZZZZZZZZZZZZZZZZZZZZZZ just wondering if a queue isn't overkill for those small amounts

Webhook vs queue for updates notifications

Similar Threads

Similar Threads

Similar Threads