# description
Enterprise Only. Apply ratelimit based on tier match.

# properties.tier_key.description
The header name containing the tier name. The string you provide is case-insensitive. If you need to take the value from a place that is not a header (a token, an API key), you must use propagate functions in the components that convert values to internal headers.

See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/

# properties.tiers.description
The list of all tier definitions and limits for each. Each item in the list is a tier object.

See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/

# properties.tiers.items.properties.tier_value.description
The tier value. When you use `literal`, it is the tier name. When you use `policy`, it is the expression you want to evaluate to determine if the user matches this tier or not (see security policies for syntax).

See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/

# properties.tiers.items.properties.tier_value_as.description
Determines how to parse the value found in the tier header. When `literal` is used, the exact value of the header is compared against the tier name. When `policy` is used, the value is used to evaluate a policy. When `*` is used, all values will match. Make sure to put the `*` as the last tier; otherwise the rest will be ignored.

See: https://www.krakend.io/docs/enterprise/docs/enterprise/service-settings/tiered-rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.description
Enterprise Only. Redis-backed service ratelimit

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.capacity.description
Defines the maximum number of [tokens a bucket can hold](https://www.krakend.io/docs/throttling/token-bucket/), or said otherwise, how many requests will you accept from **all users together** at **any given instant**. When the gateway starts, the bucket is full. As requests from users come, the remaining tokens in the bucket decrease. At the same time, the `max_rate` refills the bucket at the desired rate until its maximum capacity is reached. The default value for the `capacity` is the `max_rate` value expressed in seconds or 1 for smaller fractions. When unsure, use the same number as `max_rate`.

See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.client_capacity.description
Defines the maximum number of [tokens a bucket can hold](https://www.krakend.io/docs/throttling/token-bucket/), or said otherwise, how many requests will you accept from **each individual user** at **any given instant**. Works just as `capacity`, but instead of having one bucket for all users, keeps a counter for every connected client and endpoint, and refills from `client_max_rate` instead of `max_rate`. The client is recognized using the `strategy` field (an IP address, a token, a header, etc.). The default value for the `client_capacity` is the `client_max_rate` value expressed in seconds or 1 for smaller fractions. When unsure, use the same number as `client_max_rate`.

See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.client_max_rate.description
Number of tokens you add to the [Token Bucket](https://www.krakend.io/docs/throttling/token-bucket/) for each individual user (*user quota*) in the time interval you want (`every`). The remaining tokens in the bucket are the requests a specific user can do. It keeps a counter for every client and endpoint. Keep in mind that every KrakenD instance keeps its counters in memory for **every single client**.

See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.connection_name.description
The connection pool name or cluster name that is used by this ratelimit. The value must match what you configured in the [Redis Connection Pool](https://www.krakend.io/docs/enterprise/service-settings/redis-connection-pools/)

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.connection_pool.description
The connection pool name that is used by this ratelimit. The value must match what you configured in the [Redis Connection Pool](https://www.krakend.io/docs/enterprise/service-settings/redis-connection-pools/)

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.every.description
Time period in which the maximum rates operate. For instance, if you set an `every` of `10m` and a rate of `5`, you are allowing 5 requests every ten minutes.

See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.key.description
Available when using `client_max_rate` and you have set a `strategy` equal to `header` or `param`. It makes no sense in other contexts. For `header` it is the header name containing the user identification (e.g., `Authorization` on tokens, or `X-Original-Forwarded-For` for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For `param` it is the name of the placeholder used in the endpoint, like `id_user` for an endpoint `/user/{id_user}`.

See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.max_rate.description
Sets the maximum number of requests all users can do in the given time frame. Internally uses the [Token Bucket](https://www.krakend.io/docs/throttling/token-bucket/) algorithm. The absence of `max_rate` in the configuration or a `0` is the equivalent to no limitation. You can use decimals if needed.

See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.on_failure_allow.description
Whether you want to allow a request to continue when the Redis connection is failing or not. The default behavior blocks the request if Redis is not responding correctly

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/redis.properties.strategy.description
Available when using `client_max_rate`. Sets the strategy you will use to set client counters. Choose `ip` when the restrictions apply to the client's IP address, or set it to `header` when there is a header that identifies a user uniquely. That header must be defined with the `key` entry.

See: https://www.krakend.io/docs/enterprise/throttling/global-rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.capacity.description
Defines the maximum number of [tokens a bucket can hold](https://www.krakend.io/docs/throttling/token-bucket/), or said otherwise, how many requests will you accept from **all users together** at **any given instant**. When the gateway starts, the bucket is full. As requests from users come, the remaining tokens in the bucket decrease. At the same time, the `max_rate` refills the bucket at the desired rate until its maximum capacity is reached. The default value for the `capacity` is the `max_rate` value expressed in seconds or 1 for smaller fractions. When unsure, use the same number as `max_rate`.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.cleanup_period.description
The cleanup period is how often the routine(s) in charge of optimizing the memory dedicated will go iterate all counters looking for outdated TTL and remove them. A low value keeps the memory slightly decreasing, but as a trade-off, it will increase the CPU dedicated to achieving this optimization. This is an advanced micro-optimization setting that should be used with caution.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.cleanup_threads.description
These are the number of routines that search for and remove outdated rate limit counters. The more routine(s) you add, the faster the memory optimization is completed, but the more CPU it will consume. Generally speaking, a single thread is more than enough because the delete operation is very fast, even with a large number of counters. This is an advanced micro-optimization setting that you should use with caution.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.client_capacity.description
Defines the maximum number of [tokens a bucket can hold](https://www.krakend.io/docs/throttling/token-bucket/), or said otherwise, how many requests will you accept from **each individual user** at **any given instant**. Works just as `capacity`, but instead of having one bucket for all users, keeps a counter for every connected client and endpoint, and refills from `client_max_rate` instead of `max_rate`. The client is recognized using the `strategy` field (an IP address, a token, a header, etc.). The default value for the `client_capacity` is the `client_max_rate` value expressed in seconds or 1 for smaller fractions. When unsure, use the same number as `client_max_rate`.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.client_max_rate.description
Number of tokens you add to the [Token Bucket](https://www.krakend.io/docs/throttling/token-bucket/) for each individual user (*user quota*) in the time interval you want (`every`). The remaining tokens in the bucket are the requests a specific user can do. It keeps a counter for every client and endpoint. Keep in mind that every KrakenD instance keeps its counters in memory for **every single client**.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.every.description
Time period in which the maximum rates operate. For instance, if you set an `every` of `10m` and a rate of `5`, you are allowing 5 requests every ten minutes.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.key.description
Available when using `client_max_rate` and you have set a `strategy` equal to `header` or `param`. It makes no sense in other contexts. For `header` it is the header name containing the user identification (e.g., `Authorization` on tokens, or `X-Original-Forwarded-For` for IPs). When they contain a list of space-separated IPs, it will take the IP from the client that hit the first trusted proxy. For `param` it is the name of the placeholder used in the endpoint, like `id_user` for an endpoint `/user/{id_user}`.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.max_rate.description
Sets the maximum number of requests all users can do in the given time frame. Internally uses the [Token Bucket](https://www.krakend.io/docs/throttling/token-bucket/) algorithm. The absence of `max_rate` in the configuration or a `0` is the equivalent to no limitation. You can use decimals if needed.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.num_shards.description
All rate limit counters are stored in memory in groups (shards). All counters in the same shard share a mutex (which controls that one counter is modified at a time), and this helps with contention. Having, for instance, 2048 shards (default) and 1M users connected concurrently (same instant) means that each user will need to coordinate writes in their counter with an average of under 500 other users (1M/2048=489). Lowering the shards might increase contention and latency but free additional memory. This is an advanced micro-optimization setting that should be used with caution.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/qos/ratelimit/route.properties.strategy.description
Available when using `client_max_rate`. Sets the strategy you will use to set client counters. Choose `ip` when the restrictions apply to the client's IP address, or set it to `header` when there is a header that identifies a user uniquely. That header must be defined with the `key` entry.

See: https://www.krakend.io/docs/endpoints/rate-limit/

# definitions.https://schemas.sourcemeta.com/krakend/v2.10/timeunits.json.$defs.timeunit.description
The amount of time you want to assign followed by its unit (e.g.: `2s`, `200ms`). Valid time units are: ns, us, (or µs), ms, s, m, h.