Multiple Azure Webjob instances on one queue (part2)

Question

I'm looking for some documentation on how to set up multiple instances of an Azure webjob that handle a single queue. I came across this article: Multiple Azure Webjob instances on one queue , which was helpful. My biggest takeaway is that if I scale out my app service to multiple instances, "Each job instance will pick a different message from the queue." That's great, and it ensures that my jobs won't be duplicated.

However, I want to know if the same is true if I create a duplicate, separate app service (with the same web job on each), and run these two (or more) instances simultaneously instead of simply "scaling out". The reason for this is simply because I need more outbound IP addresses. A third party api consumed by my web job throttles me by IP address. So as my app is gaining more users, and I "scale out", I start getting more and more timeouts from this third part API. My proposed solution is to create separate app services that are essentially cloned. But I want to be sure that the jobs that come from the queue will not be duplicated.

For reference, here is what my web job function looks like:

public void ProcessQueueMessageAsync([QueueTrigger("quicktransferqueue")] string message, ILogger logger)
{
    var model = Newtonsoft.Json.JsonConvert.DeserializeObject<QuickTransferModel>(message);
    //Hit my third-party API here...
}

Answer 1

WebJobs (and Azure Functions) using a QueueTrigger will handle the queue message visibility for you and immediately hide a message when it goes to process it. This effectively locks it from other workers taking it for a given interval (it doesn't remove it from the queue immediately in case your function fails). It will be deleted upon successful completion of your function call. It doesn't matter if the QueueTrigger is from multiple instances of a single function or multiple different functions all accessing the same queue. Because they immediately "hide" the messages that they pull, another process trying to poll the queue won't see those that are actively being processed. The queue itself doesn't know how many differnt jobs/functions are trying to access it -- it's just managing the messages and their visibility. In short, you're safe.