How-To: Control concurrency and rate limit applications

Control how many requests and events will invoke your application simultaneously

A common scenario in distributed computing is to only allow for a given number of requests to execute concurrently. Using Dapr, you can control how many requests and events will invoke your application simultaneously.

Note that this rate limiting is guaranteed for every event that’s coming from Dapr, meaning Pub/Sub events, direct invocation from other services, bindings events etc. Dapr can’t enforce the concurrency policy on requests that are coming to your app externally.

*Note that rate limiting per second can be achieved by using the middleware.http.ratelimit middleware. However, there is an important difference between the two approaches. The rate limit middleware is time bound and limits the number of requests per second, while the app-max-concurrency flag specifies the number of concurrent requests (and events) at any point of time. See Rate limit middleware. *

Watch this video on how to control concurrency and rate limiting “.

Setting app-max-concurrency

Without using Dapr, a developer would need to create some sort of a semaphore in the application and take care of acquiring and releasing it. Using Dapr, there are no code changes needed to an app.

Setting app-max-concurrency in Kubernetes

To set app-max-concurrency in Kubernetes, add the following annotation to your pod:

apiVersion: apps/v1
kind: Deployment
  name: nodesubscriber
  namespace: default
    app: nodesubscriber
  replicas: 1
      app: nodesubscriber
        app: nodesubscriber
      annotations: "true" "nodesubscriber" "3000" "1"

Setting app-max-concurrency using the Dapr CLI

To set app-max-concurrency with the Dapr CLI for running on your local dev machine, add the app-max-concurrency flag:

dapr run --app-max-concurrency 1 --app-port 5000 python ./

The above examples will effectively turn your app into a single concurrent service.