NoSpoon

Have you ever tried to throttle a Function that is hosted on a consumption plan?
Well if you have, then you know of some of the problems that you run into.
Given a Durable Function that does a fan-out and gets data from an API that needed throtteling, this is what I came up with.

Now the first thing I tried is of course to look at any way in the function settings to limit this, and this is what I found when checking out the host.JSON reference on microsoft docs.

"http": {
        "routePrefix": "api",
        "maxOutstandingRequests": 200,
        "maxConcurrentRequests": 100,
        "dynamicThrottlesEnabled": true
    }

When scrolling through, I found maxConcurrentRequests among others. Now this looked promising but when I researched it, I found that it does not really do the trick when using the consumption plan. That is because of the nature of the consumption plan, it auto scales, and the setting is per instance. In other words for every server it scales out to, it will set the maxConcurrentRequests.

OK, what now?
Well then I found this little beauty:

"WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT" : 1

The WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT is an application setting that at the moment is in preview, but will work for this solution.

After having made shure that the application can not scale out dynamicly, I needed to constrain the number of active requests or active calls to the API. Luckily Durable Functions had the answer to that giving me the possibility to set the maxConcurrentActivityFunctions making it possible for me to limit traffic to my API.

"durableTask": {
    "maxConcurrentActivityFunctions": 10,
    "maxConcurrentOrchestratorFunctions": 1
  }

I did not explore if a combination of 
WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT and 
maxConcurrentRequests could be used. But as the given solution fit my needs…
I also did not look at changing the PartitionCount setting.
I may take a look at these another time.