I'm implementing a webhooks provider and trying to solve some problems while minimizing the added complexity to my system:

Not blocking processing of the API call that triggered the event while calling all the hooks so the response to that call will not be delayed
Not making a flood of calls to my listeners if some client is quickly calling my APIs that trigger hooks (i.e. wait a couple seconds and throw away any earlier calls if duplicates come in later)

My environment is Python (Chalice) and AWS Lambda. Ideal solution will be easy to integrate and cheap.
I would use SQS / SNS depending on exact architecture design. Maybe Apache Kafka, if you need to store events longer... 
So upcoming event would be placed on SQS, and then other lambda would be used to do processing. Problem is that time of processing is limited to 5 min. Also delivering can't be parallel. 
Other option is to have one input queue, and one output queue per receiver. So the lambda function, which process input, just spreads it through other queues. And then other lambdas are responsible for delivering. That way has other obvious problems.
Finally. Your lambda, while processing input, can generate messages on outgoing queue, instrumenting what message should be delivered to which users. Then you can have one lambda triggered on each message from outgoing queue. And there you can have small loop delivering messages. Note that in case of problems you need to send back what was not delivered. 
Good point is that SQS has something like dead letter queue, so that problematic messages would not stay there forever.
Design for implementing web hooks (including not blocking and ignoring superseding repeat events)