> If you're using a monolithic setup with erlang or running any kind of queue on the side you are fine. You might need to setup some retry logic and alerts but that is done once.
I could be misunderstanding but I think the argument is
if something/somebody is pushing to your webhook URL, and you are down for whatever moment of time, unless they retry, you lost the message
therefore
that's why you ask the entity pushing the data to your webhook to put it into something that is high availability (like an HTTP frontend to AWS SQS I'm guessing), and then you get around to processing it on your end when you can
Webhooks seem to be the publish/subscriber side of message queues without any of the "acknowledge successful processing of the message" parts defined in standard. 5 different companies pushing 5 different webhooks might all handle timeouts/500 errors/ECONNRESET differently retry wise.
I could be misunderstanding but I think the argument is
if something/somebody is pushing to your webhook URL, and you are down for whatever moment of time, unless they retry, you lost the message
therefore
that's why you ask the entity pushing the data to your webhook to put it into something that is high availability (like an HTTP frontend to AWS SQS I'm guessing), and then you get around to processing it on your end when you can
Webhooks seem to be the publish/subscriber side of message queues without any of the "acknowledge successful processing of the message" parts defined in standard. 5 different companies pushing 5 different webhooks might all handle timeouts/500 errors/ECONNRESET differently retry wise.