One potential issue with this approach is the risk of a webhook bottleneck since all incoming requests hit the same webhook initially.
I think that using queue mode with separate instances for main, workers, and webhooks, and Redis managing the queue, would solve this potential bottleneck, right? Should I still be concerned about a bottleneck at the webhook level?
Would it be more efficient to use a separate webhook for each endpoint instead?
Remember that node.js handles web requests (and everything else) in a single-threaded, non-blocking way. The way n8n handles and queues workflow triggers may also be relevant, but there is already kind-of a bottleneck, and already mitigation for that (promises/async) in node.js.
I would only worry about it after you run a test at the concurrency/load level you expect, and observe an actual problem.
If you aren’t already familiar with it, this gives a reasonably good explanation of the node.js “event loop.”
It all depends.
Scaling with webhook workers and such should do the trick in most cases. But of course it depends on your servers and the resources available if it can process everything intime.
Best is to offload work to a queue like rabbitmq where you can to clear some of the resources faster.