Dapr · Rate Limits
Dapr Rate Limits
Dapr is a self-hosted runtime; there is no provider-imposed rate limit on the Dapr APIs. Throughput is bounded by the operator's own sidecar resource limits, the underlying state store / message broker, and any Dapr Resiliency or Configuration policies the operator configures (rate limit middleware, circuit breakers, timeouts, retries). Dapr does ship a rate-limit HTTP middleware component that operators can attach to any building-block invocation, but the numeric limits are always operator-defined.
2 Limits
Throttle: 429
Distributed SystemsMicroservicesOpen SourceRate Limiting
Limits
Operator-configured rate limit middleware per-component
operator-defined via ratelimit middleware component
Configured in the rate-limit middleware spec (`maxRequestsPerSecond`) and bound to a pipeline. No default; not applied unless the middleware is attached.
Operator-configured Resiliency policy per-component or per-app
operator-defined via Resiliency CRDs (timeouts, retries, circuit breakers)
Resiliency policies bound circuit-breaker thresholds, retry budgets, and timeouts; they are not vendor rate limits.
Policies
Self-Hosted Throttling
Because Dapr runs in the operator's own infrastructure, all throughput limits are under operator control. Tune sidecar CPU/memory, state-store throughput, and broker partitions to set effective limits.
Middleware Pattern
Use the rate-limit HTTP middleware to enforce a per-app requests-per-second cap; attach it to specific building blocks via component pipelines.
Resiliency First
Combine timeouts, retries with backoff, and circuit breakers via Resiliency CRDs rather than relying on a single rate-limit number. Dapr's Resiliency framework is the canonical place to encode these.