Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
Baoyuantop merged PR #2028: URL: https://github.com/apache/apisix-website/pull/2028 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
nic-6443 commented on code in PR #2028:
URL: https://github.com/apache/apisix-website/pull/2028#discussion_r3090500621
##
blog/en/blog/2026/04/14/apisix-3.16-dynamic-rate-limiting.md:
##
@@ -0,0 +1,329 @@
+---
+title: "What's New in Apache APISIX 3.16: Dynamic Rate Limiting for Your API
Gateway"
+authors:
+ - name: "Ming Wen"
+title: "Author"
+url: "https://github.com/moonming";
+image_url: "https://github.com/moonming.png";
+keywords:
+ - Apache APISIX
+ - API Gateway
+ - Rate Limiting
+ - Dynamic Rate Limiting
+ - AI Gateway
+ - Multi-Tenant
+ - Token Budget
+description: Apache APISIX 3.16 introduces dynamic rate limiting with multiple
rules and variable support across limit-count, limit-conn, and ai-rate-limiting
plugins, enabling context-aware, per-tier, and multi-tenant rate limiting in a
single route configuration.
+tags: [Products]
+---
+
+Rate limiting is one of the most critical capabilities in any API gateway. Yet
for years, most gateways — including APISIX — have treated it as a static,
one-size-fits-all configuration: set a number, set a time window, done.
+
+In practice, real-world rate limiting is far more nuanced. A SaaS platform
needs different quotas for free and paid users. An AI gateway must enforce
token budgets that vary by model and consumer. A multi-tenant API must isolate
rate limits per tenant without duplicating routes.
+
+Apache APISIX 3.16 addresses these challenges head-on with two powerful
enhancements to the rate limiting plugins: **multiple rules** and **variable
support**. Together, they transform rate limiting from static configuration
into a dynamic, context-aware policy engine.
+
+
+
+## What Changed in APISIX 3.16
+
+APISIX 3.16 introduces two complementary features across the `limit-count`,
`limit-conn`, and `ai-rate-limiting` plugins:
+
+| Feature | Description | Supported Plugins |
+|-|-|---|
+| Multiple rules | Define an array of rate limiting rules with independent
thresholds and time windows | `limit-count`, `limit-conn`, `ai-rate-limiting` |
+| Variable support | Use APISIX variables (`${remote_addr}`, `${http_*}`,
`${consumer_name}`, etc.) in `count`, `time_window`, and `key` fields, with
optional default values via `${var ?? default}` | `limit-count`, `limit-conn`,
`ai-rate-limiting` |
+
+Both features are fully backward compatible. Existing configurations continue
to work without modification.
+
+## Multiple Rules: Beyond Single-Threshold Rate Limiting
+
+### The Problem
+
+Consider a common requirement: limit an API to **10 requests per second** and
**500 requests per minute**. Before 3.16, you had to configure two separate
plugin instances or chain multiple routes. This was verbose, error-prone, and
hard to maintain.
+
+### The Solution
+
+The new `rules` array lets you define multiple rate limiting policies in a
single plugin configuration. Each rule operates independently with its own
counter, time window, and key.
+
+```json
+{
+ "uri": "/api/v1/*",
+ "plugins": {
+"limit-count": {
+ "rules": [
+{
+ "count": 10,
+ "time_window": 1,
+ "key": "${remote_addr}_per_second",
+ "header_prefix": "per-second"
+},
+{
+ "count": 500,
+ "time_window": 60,
+ "key": "${remote_addr}_per_minute",
+ "header_prefix": "per-minute"
+},
+{
+ "count": 1,
+ "time_window": 86400,
+ "key": "${remote_addr}_per_day",
+ "header_prefix": "per-day"
+}
+ ],
+ "rejected_code": 429
+}
+ },
+ "upstream": {
+"type": "roundrobin",
+"nodes": {
+ "127.0.0.1:1980": 1
+}
+ }
+}
+```
+
+With this configuration, APISIX enforces all three limits simultaneously. A
client hitting the per-second limit receives a `429` response with headers
indicating which limit was exceeded:
+
+```
+X-Per-Second-RateLimit-Limit: 10
+X-Per-Second-RateLimit-Remaining: 0
+X-Per-Second-RateLimit-Reset: 1
+X-Per-Minute-RateLimit-Limit: 500
+X-Per-Minute-RateLimit-Remaining: 499
+X-Per-Minute-RateLimit-Reset: 60
+```
+
+The `header_prefix` field lets clients distinguish which rule triggered the
rejection — critical for debugging and client-side retry logic.
+
+## Variable Support: Context-Aware Rate Limiting
+
+### The Problem
+
+Static rate limits assume every consumer is equal. In reality, a free-tier
user and an enterprise customer should have very different quotas. Before 3.16,
supporting this meant creating separate routes for each tier — leading to route
explosion and configuration drift.
+
+### The Solution
+
+Variable support lets you pull rate limiting parameters directly from the
request context. The `count`, `time_window`, and `key` fields now accept APISIX
variables.
+
+### Example 1: Per-Tier Rate Limiting via HTTP Header
+
+Suppose your authentication middleware injects an `X-Rate-Quota` header based
Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
nic-6443 commented on code in PR #2028:
URL: https://github.com/apache/apisix-website/pull/2028#discussion_r3090499110
##
blog/en/blog/2026/04/14/apisix-3.16-dynamic-rate-limiting.md:
##
@@ -0,0 +1,329 @@
+---
+title: "What's New in Apache APISIX 3.16: Dynamic Rate Limiting for Your API
Gateway"
+authors:
+ - name: "Ming Wen"
+title: "Author"
+url: "https://github.com/moonming";
+image_url: "https://github.com/moonming.png";
+keywords:
+ - Apache APISIX
+ - API Gateway
+ - Rate Limiting
+ - Dynamic Rate Limiting
+ - AI Gateway
+ - Multi-Tenant
+ - Token Budget
+description: Apache APISIX 3.16 introduces dynamic rate limiting with multiple
rules and variable support across limit-count, limit-conn, and ai-rate-limiting
plugins, enabling context-aware, per-tier, and multi-tenant rate limiting in a
single route configuration.
+tags: [Products]
+---
+
+Rate limiting is one of the most critical capabilities in any API gateway. Yet
for years, most gateways — including APISIX — have treated it as a static,
one-size-fits-all configuration: set a number, set a time window, done.
+
+In practice, real-world rate limiting is far more nuanced. A SaaS platform
needs different quotas for free and paid users. An AI gateway must enforce
token budgets that vary by model and consumer. A multi-tenant API must isolate
rate limits per tenant without duplicating routes.
+
+Apache APISIX 3.16 addresses these challenges head-on with two powerful
enhancements to the rate limiting plugins: **multiple rules** and **variable
support**. Together, they transform rate limiting from static configuration
into a dynamic, context-aware policy engine.
+
+
+
+## What Changed in APISIX 3.16
+
+APISIX 3.16 introduces two complementary features across the `limit-count`,
`limit-conn`, and `ai-rate-limiting` plugins:
+
+| Feature | Description | Supported Plugins |
+|-|-|---|
+| Multiple rules | Define an array of rate limiting rules with independent
thresholds and time windows | `limit-count`, `limit-conn`, `ai-rate-limiting` |
+| Variable support | Use APISIX variables (`${remote_addr}`, `${http_*}`,
`${consumer_name}`, etc.) in `count`, `time_window`, and `key` fields, with
optional default values via `${var ?? default}` | `limit-count`, `limit-conn`,
`ai-rate-limiting` |
+
+Both features are fully backward compatible. Existing configurations continue
to work without modification.
+
+## Multiple Rules: Beyond Single-Threshold Rate Limiting
+
+### The Problem
+
+Consider a common requirement: limit an API to **10 requests per second** and
**500 requests per minute**. Before 3.16, you had to configure two separate
plugin instances or chain multiple routes. This was verbose, error-prone, and
hard to maintain.
+
+### The Solution
+
+The new `rules` array lets you define multiple rate limiting policies in a
single plugin configuration. Each rule operates independently with its own
counter, time window, and key.
+
+```json
+{
+ "uri": "/api/v1/*",
+ "plugins": {
+"limit-count": {
+ "rules": [
+{
+ "count": 10,
+ "time_window": 1,
+ "key": "${remote_addr}_per_second",
+ "header_prefix": "per-second"
+},
+{
+ "count": 500,
+ "time_window": 60,
+ "key": "${remote_addr}_per_minute",
+ "header_prefix": "per-minute"
+},
+{
+ "count": 1,
+ "time_window": 86400,
+ "key": "${remote_addr}_per_day",
+ "header_prefix": "per-day"
+}
+ ],
+ "rejected_code": 429
+}
+ },
+ "upstream": {
+"type": "roundrobin",
+"nodes": {
+ "127.0.0.1:1980": 1
+}
+ }
+}
+```
+
+With this configuration, APISIX enforces all three limits simultaneously. A
client hitting the per-second limit receives a `429` response with headers
indicating which limit was exceeded:
+
+```
+X-Per-Second-RateLimit-Limit: 10
+X-Per-Second-RateLimit-Remaining: 0
+X-Per-Second-RateLimit-Reset: 1
+X-Per-Minute-RateLimit-Limit: 500
+X-Per-Minute-RateLimit-Remaining: 499
+X-Per-Minute-RateLimit-Reset: 60
+```
+
+The `header_prefix` field lets clients distinguish which rule triggered the
rejection — critical for debugging and client-side retry logic.
+
+## Variable Support: Context-Aware Rate Limiting
+
+### The Problem
+
+Static rate limits assume every consumer is equal. In reality, a free-tier
user and an enterprise customer should have very different quotas. Before 3.16,
supporting this meant creating separate routes for each tier — leading to route
explosion and configuration drift.
+
+### The Solution
+
+Variable support lets you pull rate limiting parameters directly from the
request context. The `count`, `time_window`, and `key` fields now accept APISIX
variables.
+
+### Example 1: Per-Tier Rate Limiting via HTTP Header
+
+Suppose your authentication middleware injects an `X-Rate-Quota` header based
Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
nic-6443 commented on code in PR #2028:
URL: https://github.com/apache/apisix-website/pull/2028#discussion_r3090449230
##
blog/en/blog/2026/04/14/apisix-3.16-dynamic-rate-limiting.md:
##
@@ -0,0 +1,329 @@
+---
+title: "What's New in Apache APISIX 3.16: Dynamic Rate Limiting for Your API
Gateway"
+authors:
+ - name: "Ming Wen"
+title: "Author"
+url: "https://github.com/moonming";
+image_url: "https://github.com/moonming.png";
+keywords:
+ - Apache APISIX
+ - API Gateway
+ - Rate Limiting
+ - Dynamic Rate Limiting
+ - AI Gateway
+ - Multi-Tenant
+ - Token Budget
+description: Apache APISIX 3.16 introduces dynamic rate limiting with multiple
rules and variable support across limit-count, limit-conn, and ai-rate-limiting
plugins, enabling context-aware, per-tier, and multi-tenant rate limiting in a
single route configuration.
+tags: [Products]
+---
+
+Rate limiting is one of the most critical capabilities in any API gateway. Yet
for years, most gateways — including APISIX — have treated it as a static,
one-size-fits-all configuration: set a number, set a time window, done.
+
+In practice, real-world rate limiting is far more nuanced. A SaaS platform
needs different quotas for free and paid users. An AI gateway must enforce
token budgets that vary by model and consumer. A multi-tenant API must isolate
rate limits per tenant without duplicating routes.
+
+Apache APISIX 3.16 addresses these challenges head-on with two powerful
enhancements to the rate limiting plugins: **multiple rules** and **variable
support**. Together, they transform rate limiting from static configuration
into a dynamic, context-aware policy engine.
+
+
+
+## What Changed in APISIX 3.16
+
+APISIX 3.16 introduces two complementary features across the `limit-count`,
`limit-conn`, and `ai-rate-limiting` plugins:
+
+| Feature | Description | Supported Plugins |
+|-|-|---|
+| Multiple rules | Define an array of rate limiting rules with independent
thresholds and time windows | `limit-count`, `limit-conn`, `ai-rate-limiting` |
+| Variable support | Use APISIX variables (`${remote_addr}`, `${http_*}`,
`${consumer_name}`, etc.) in `count`, `time_window`, and `key` fields, with
optional default values via `${var ?? default}` | `limit-count`, `limit-conn`,
`ai-rate-limiting` |
+
+Both features are fully backward compatible. Existing configurations continue
to work without modification.
+
+## Multiple Rules: Beyond Single-Threshold Rate Limiting
+
+### The Problem
+
+Consider a common requirement: limit an API to **10 requests per second** and
**500 requests per minute**. Before 3.16, you had to configure two separate
plugin instances or chain multiple routes. This was verbose, error-prone, and
hard to maintain.
+
+### The Solution
+
+The new `rules` array lets you define multiple rate limiting policies in a
single plugin configuration. Each rule operates independently with its own
counter, time window, and key.
+
+```json
+{
+ "uri": "/api/v1/*",
+ "plugins": {
+"limit-count": {
+ "rules": [
+{
+ "count": 10,
+ "time_window": 1,
+ "key": "${remote_addr}_per_second",
+ "header_prefix": "per-second"
+},
+{
+ "count": 500,
+ "time_window": 60,
+ "key": "${remote_addr}_per_minute",
+ "header_prefix": "per-minute"
+},
+{
+ "count": 1,
+ "time_window": 86400,
+ "key": "${remote_addr}_per_day",
+ "header_prefix": "per-day"
+}
+ ],
+ "rejected_code": 429
+}
+ },
+ "upstream": {
+"type": "roundrobin",
+"nodes": {
+ "127.0.0.1:1980": 1
+}
+ }
+}
+```
+
+With this configuration, APISIX enforces all three limits simultaneously. A
client hitting the per-second limit receives a `429` response with headers
indicating which limit was exceeded:
+
+```
+X-Per-Second-RateLimit-Limit: 10
+X-Per-Second-RateLimit-Remaining: 0
+X-Per-Second-RateLimit-Reset: 1
+X-Per-Minute-RateLimit-Limit: 500
+X-Per-Minute-RateLimit-Remaining: 499
+X-Per-Minute-RateLimit-Reset: 60
+```
+
+The `header_prefix` field lets clients distinguish which rule triggered the
rejection — critical for debugging and client-side retry logic.
+
+## Variable Support: Context-Aware Rate Limiting
+
+### The Problem
+
+Static rate limits assume every consumer is equal. In reality, a free-tier
user and an enterprise customer should have very different quotas. Before 3.16,
supporting this meant creating separate routes for each tier — leading to route
explosion and configuration drift.
+
+### The Solution
+
+Variable support lets you pull rate limiting parameters directly from the
request context. The `count`, `time_window`, and `key` fields now accept APISIX
variables.
+
+### Example 1: Per-Tier Rate Limiting via HTTP Header
+
+Suppose your authentication middleware injects an `X-Rate-Quota` header based
Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
Yilialinn commented on code in PR #2028:
URL: https://github.com/apache/apisix-website/pull/2028#discussion_r3086422244
##
blog/en/blog/2026/04/14/apisix-3.16-dynamic-rate-limiting.md:
##
@@ -0,0 +1,329 @@
+---
+title: "What's New in Apache APISIX 3.16: Dynamic Rate Limiting for Your API
Gateway"
+authors:
+ - name: "Ming Wen"
+title: "Author"
+url: "https://github.com/moonming";
+image_url: "https://github.com/moonming.png";
+keywords:
+ - Apache APISIX
+ - API Gateway
+ - Rate Limiting
+ - Dynamic Rate Limiting
+ - AI Gateway
+ - Multi-Tenant
+ - Token Budget
+description: Apache APISIX 3.16 introduces dynamic rate limiting with multiple
rules and variable support across limit-count, limit-conn, and ai-rate-limiting
plugins, enabling context-aware, per-tier, and multi-tenant rate limiting in a
single route configuration.
+tags: [Products]
+---
+
+Rate limiting is one of the most critical capabilities in any API gateway. Yet
for years, most gateways — including APISIX — have treated it as a static,
one-size-fits-all configuration: set a number, set a time window, done.
+
+In practice, real-world rate limiting is far more nuanced. A SaaS platform
needs different quotas for free and paid users. An AI gateway must enforce
token budgets that vary by model and consumer. A multi-tenant API must isolate
rate limits per tenant without duplicating routes.
+
+Apache APISIX 3.16 addresses these challenges head-on with two powerful
enhancements to the rate limiting plugins: **multiple rules** and **variable
support**. Together, they transform rate limiting from static configuration
into a dynamic, context-aware policy engine.
+
+
+
+## What Changed in APISIX 3.16
+
+APISIX 3.16 introduces two complementary features across the `limit-count`,
`limit-conn`, and `ai-rate-limiting` plugins:
+
+| Feature | Description | Supported Plugins |
+|-|-|---|
+| Multiple rules | Define an array of rate limiting rules with independent
thresholds and time windows | `limit-count`, `limit-conn`, `ai-rate-limiting` |
+| Variable support | Use APISIX variables (`${remote_addr}`, `${http_*}`,
`${consumer_name}`, etc.) in `count`, `time_window`, and `key` fields, with
optional default values via `${var ?? default}` | `limit-count`, `limit-conn`,
`ai-rate-limiting` |
+
+Both features are fully backward compatible. Existing configurations continue
to work without modification.
+
+## Multiple Rules: Beyond Single-Threshold Rate Limiting
+
+### The Problem
+
+Consider a common requirement: limit an API to **10 requests per second** and
**500 requests per minute**. Before 3.16, you had to configure two separate
plugin instances or chain multiple routes. This was verbose, error-prone, and
hard to maintain.
+
+### The Solution
+
+The new `rules` array lets you define multiple rate limiting policies in a
single plugin configuration. Each rule operates independently with its own
counter, time window, and key.
+
+```json
+{
+ "uri": "/api/v1/*",
+ "plugins": {
+"limit-count": {
+ "rules": [
+{
+ "count": 10,
+ "time_window": 1,
+ "key": "${remote_addr}_per_second",
+ "header_prefix": "per-second"
+},
+{
+ "count": 500,
+ "time_window": 60,
+ "key": "${remote_addr}_per_minute",
+ "header_prefix": "per-minute"
+},
+{
+ "count": 1,
+ "time_window": 86400,
+ "key": "${remote_addr}_per_day",
+ "header_prefix": "per-day"
+}
+ ],
+ "rejected_code": 429
+}
+ },
+ "upstream": {
+"type": "roundrobin",
+"nodes": {
+ "127.0.0.1:1980": 1
+}
+ }
+}
+```
+
+With this configuration, APISIX enforces all three limits simultaneously. A
client hitting the per-second limit receives a `429` response with headers
indicating which limit was exceeded:
+
+```
+X-Per-Second-RateLimit-Limit: 10
+X-Per-Second-RateLimit-Remaining: 0
+X-Per-Second-RateLimit-Reset: 1
+X-Per-Minute-RateLimit-Limit: 500
+X-Per-Minute-RateLimit-Remaining: 499
+X-Per-Minute-RateLimit-Reset: 60
+```
+
+The `header_prefix` field lets clients distinguish which rule triggered the
rejection — critical for debugging and client-side retry logic.
+
+## Variable Support: Context-Aware Rate Limiting
+
+### The Problem
+
+Static rate limits assume every consumer is equal. In reality, a free-tier
user and an enterprise customer should have very different quotas. Before 3.16,
supporting this meant creating separate routes for each tier — leading to route
explosion and configuration drift.
+
+### The Solution
+
+Variable support lets you pull rate limiting parameters directly from the
request context. The `count`, `time_window`, and `key` fields now accept APISIX
variables.
+
+### Example 1: Per-Tier Rate Limiting via HTTP Header
+
+Suppose your authentication middleware injects an `X-Rate-Quota` header based
Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
Yilialinn commented on code in PR #2028:
URL: https://github.com/apache/apisix-website/pull/2028#discussion_r3086422244
##
blog/en/blog/2026/04/14/apisix-3.16-dynamic-rate-limiting.md:
##
@@ -0,0 +1,329 @@
+---
+title: "What's New in Apache APISIX 3.16: Dynamic Rate Limiting for Your API
Gateway"
+authors:
+ - name: "Ming Wen"
+title: "Author"
+url: "https://github.com/moonming";
+image_url: "https://github.com/moonming.png";
+keywords:
+ - Apache APISIX
+ - API Gateway
+ - Rate Limiting
+ - Dynamic Rate Limiting
+ - AI Gateway
+ - Multi-Tenant
+ - Token Budget
+description: Apache APISIX 3.16 introduces dynamic rate limiting with multiple
rules and variable support across limit-count, limit-conn, and ai-rate-limiting
plugins, enabling context-aware, per-tier, and multi-tenant rate limiting in a
single route configuration.
+tags: [Products]
+---
+
+Rate limiting is one of the most critical capabilities in any API gateway. Yet
for years, most gateways — including APISIX — have treated it as a static,
one-size-fits-all configuration: set a number, set a time window, done.
+
+In practice, real-world rate limiting is far more nuanced. A SaaS platform
needs different quotas for free and paid users. An AI gateway must enforce
token budgets that vary by model and consumer. A multi-tenant API must isolate
rate limits per tenant without duplicating routes.
+
+Apache APISIX 3.16 addresses these challenges head-on with two powerful
enhancements to the rate limiting plugins: **multiple rules** and **variable
support**. Together, they transform rate limiting from static configuration
into a dynamic, context-aware policy engine.
+
+
+
+## What Changed in APISIX 3.16
+
+APISIX 3.16 introduces two complementary features across the `limit-count`,
`limit-conn`, and `ai-rate-limiting` plugins:
+
+| Feature | Description | Supported Plugins |
+|-|-|---|
+| Multiple rules | Define an array of rate limiting rules with independent
thresholds and time windows | `limit-count`, `limit-conn`, `ai-rate-limiting` |
+| Variable support | Use APISIX variables (`${remote_addr}`, `${http_*}`,
`${consumer_name}`, etc.) in `count`, `time_window`, and `key` fields, with
optional default values via `${var ?? default}` | `limit-count`, `limit-conn`,
`ai-rate-limiting` |
+
+Both features are fully backward compatible. Existing configurations continue
to work without modification.
+
+## Multiple Rules: Beyond Single-Threshold Rate Limiting
+
+### The Problem
+
+Consider a common requirement: limit an API to **10 requests per second** and
**500 requests per minute**. Before 3.16, you had to configure two separate
plugin instances or chain multiple routes. This was verbose, error-prone, and
hard to maintain.
+
+### The Solution
+
+The new `rules` array lets you define multiple rate limiting policies in a
single plugin configuration. Each rule operates independently with its own
counter, time window, and key.
+
+```json
+{
+ "uri": "/api/v1/*",
+ "plugins": {
+"limit-count": {
+ "rules": [
+{
+ "count": 10,
+ "time_window": 1,
+ "key": "${remote_addr}_per_second",
+ "header_prefix": "per-second"
+},
+{
+ "count": 500,
+ "time_window": 60,
+ "key": "${remote_addr}_per_minute",
+ "header_prefix": "per-minute"
+},
+{
+ "count": 1,
+ "time_window": 86400,
+ "key": "${remote_addr}_per_day",
+ "header_prefix": "per-day"
+}
+ ],
+ "rejected_code": 429
+}
+ },
+ "upstream": {
+"type": "roundrobin",
+"nodes": {
+ "127.0.0.1:1980": 1
+}
+ }
+}
+```
+
+With this configuration, APISIX enforces all three limits simultaneously. A
client hitting the per-second limit receives a `429` response with headers
indicating which limit was exceeded:
+
+```
+X-Per-Second-RateLimit-Limit: 10
+X-Per-Second-RateLimit-Remaining: 0
+X-Per-Second-RateLimit-Reset: 1
+X-Per-Minute-RateLimit-Limit: 500
+X-Per-Minute-RateLimit-Remaining: 499
+X-Per-Minute-RateLimit-Reset: 60
+```
+
+The `header_prefix` field lets clients distinguish which rule triggered the
rejection — critical for debugging and client-side retry logic.
+
+## Variable Support: Context-Aware Rate Limiting
+
+### The Problem
+
+Static rate limits assume every consumer is equal. In reality, a free-tier
user and an enterprise customer should have very different quotas. Before 3.16,
supporting this meant creating separate routes for each tier — leading to route
explosion and configuration drift.
+
+### The Solution
+
+Variable support lets you pull rate limiting parameters directly from the
request context. The `count`, `time_window`, and `key` fields now accept APISIX
variables.
+
+### Example 1: Per-Tier Rate Limiting via HTTP Header
+
+Suppose your authentication middleware injects an `X-Rate-Quota` header based
Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
Yilialinn commented on code in PR #2028:
URL: https://github.com/apache/apisix-website/pull/2028#discussion_r3085433623
##
blog/en/blog/2026/04/14/apisix-3.16-dynamic-rate-limiting.md:
##
@@ -0,0 +1,329 @@
+---
+title: "What's New in Apache APISIX 3.16: Dynamic Rate Limiting for Your API
Gateway"
+authors:
+ - name: "Ming Wen"
+title: "Author"
+url: "https://github.com/moonming";
+image_url: "https://github.com/moonming.png";
+keywords:
+ - Apache APISIX
+ - API Gateway
+ - Rate Limiting
+ - Dynamic Rate Limiting
+ - AI Gateway
+ - Multi-Tenant
+ - Token Budget
+description: Apache APISIX 3.16 introduces dynamic rate limiting with multiple
rules and variable support across limit-count, limit-conn, and ai-rate-limiting
plugins, enabling context-aware, per-tier, and multi-tenant rate limiting in a
single route configuration.
+tags: [Products]
+---
+
+Rate limiting is one of the most critical capabilities in any API gateway. Yet
for years, most gateways — including APISIX — have treated it as a static,
one-size-fits-all configuration: set a number, set a time window, done.
+
+In practice, real-world rate limiting is far more nuanced. A SaaS platform
needs different quotas for free and paid users. An AI gateway must enforce
token budgets that vary by model and consumer. A multi-tenant API must isolate
rate limits per tenant without duplicating routes.
+
+Apache APISIX 3.16 addresses these challenges head-on with two powerful
enhancements to the rate limiting plugins: **multiple rules** and **variable
support**. Together, they transform rate limiting from static configuration
into a dynamic, context-aware policy engine.
+
+
+
+## What Changed in APISIX 3.16
+
+APISIX 3.16 introduces two complementary features across the `limit-count`,
`limit-conn`, and `ai-rate-limiting` plugins:
+
+| Feature | Description | Supported Plugins |
+|-|-|---|
+| Multiple rules | Define an array of rate limiting rules with independent
thresholds and time windows | `limit-count`, `limit-conn`, `ai-rate-limiting` |
+| Variable support | Use APISIX variables (`${remote_addr}`, `${http_*}`,
`${consumer_name}`, etc.) in `count`, `time_window`, and `key` fields, with
optional default values via `${var ?? default}` | `limit-count`, `limit-conn`,
`ai-rate-limiting` |
+
+Both features are fully backward compatible. Existing configurations continue
to work without modification.
+
+## Multiple Rules: Beyond Single-Threshold Rate Limiting
+
+### The Problem
+
+Consider a common requirement: limit an API to **10 requests per second** and
**500 requests per minute**. Before 3.16, you had to configure two separate
plugin instances or chain multiple routes. This was verbose, error-prone, and
hard to maintain.
+
+### The Solution
+
+The new `rules` array lets you define multiple rate limiting policies in a
single plugin configuration. Each rule operates independently with its own
counter, time window, and key.
+
+```json
+{
+ "uri": "/api/v1/*",
+ "plugins": {
+"limit-count": {
+ "rules": [
+{
+ "count": 10,
+ "time_window": 1,
+ "key": "${remote_addr}_per_second",
+ "header_prefix": "per-second"
+},
+{
+ "count": 500,
+ "time_window": 60,
+ "key": "${remote_addr}_per_minute",
+ "header_prefix": "per-minute"
+},
+{
+ "count": 1,
+ "time_window": 86400,
+ "key": "${remote_addr}_per_day",
+ "header_prefix": "per-day"
+}
+ ],
+ "rejected_code": 429
+}
+ },
+ "upstream": {
+"type": "roundrobin",
+"nodes": {
+ "127.0.0.1:1980": 1
+}
+ }
+}
+```
+
+With this configuration, APISIX enforces all three limits simultaneously. A
client hitting the per-second limit receives a `429` response with headers
indicating which limit was exceeded:
+
+```
+X-Per-Second-RateLimit-Limit: 10
+X-Per-Second-RateLimit-Remaining: 0
+X-Per-Second-RateLimit-Reset: 1
+X-Per-Minute-RateLimit-Limit: 500
+X-Per-Minute-RateLimit-Remaining: 499
+X-Per-Minute-RateLimit-Reset: 60
+```
+
+The `header_prefix` field lets clients distinguish which rule triggered the
rejection — critical for debugging and client-side retry logic.
+
+## Variable Support: Context-Aware Rate Limiting
+
+### The Problem
+
+Static rate limits assume every consumer is equal. In reality, a free-tier
user and an enterprise customer should have very different quotas. Before 3.16,
supporting this meant creating separate routes for each tier — leading to route
explosion and configuration drift.
+
+### The Solution
+
+Variable support lets you pull rate limiting parameters directly from the
request context. The `count`, `time_window`, and `key` fields now accept APISIX
variables.
+
+### Example 1: Per-Tier Rate Limiting via HTTP Header
+
+Suppose your authentication middleware injects an `X-Rate-Quota` header based
Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
Baoyuantop commented on code in PR #2028:
URL: https://github.com/apache/apisix-website/pull/2028#discussion_r3080363426
##
blog/en/blog/2026/04/14/apisix-3.16-dynamic-rate-limiting.md:
##
@@ -0,0 +1,328 @@
+---
+title: "What's New in Apache APISIX 3.16: Dynamic Rate Limiting for Your API
Gateway"
+authors:
+ - name: "Ming Wen"
+title: "Author"
+url: "https://github.com/moonming";
+image_url: "https://github.com/moonming.png";
+keywords:
+ - Apache APISIX
+ - API Gateway
+ - Rate Limiting
+ - Dynamic Rate Limiting
+ - AI Gateway
+ - Multi-Tenant
+ - Token Budget
+description: Apache APISIX 3.16 introduces dynamic rate limiting with multiple
rules and variable support across limit-count, limit-conn, and ai-rate-limiting
plugins, enabling context-aware, per-tier, and multi-tenant rate limiting in a
single route configuration.
+tags: [Products]
+---
+
+Rate limiting is one of the most critical capabilities in any API gateway. Yet
for years, most gateways — including APISIX — have treated it as a static,
one-size-fits-all configuration: set a number, set a time window, done.
+
+In practice, real-world rate limiting is far more nuanced. A SaaS platform
needs different quotas for free and paid users. An AI gateway must enforce
token budgets that vary by model and consumer. A multi-tenant API must isolate
rate limits per tenant without duplicating routes.
+
+Apache APISIX 3.16 addresses these challenges head-on with two powerful
enhancements to the rate limiting plugins: **multiple rules** and **variable
support**. Together, they transform rate limiting from static configuration
into a dynamic, context-aware policy engine.
+
+
+
+## What Changed in APISIX 3.16
+
+APISIX 3.16 introduces two complementary features across the `limit-count`,
`limit-conn`, and `ai-rate-limiting` plugins:
+
+| Feature | Description | Supported Plugins |
+|-|-|---|
+| Multiple rules | Define an array of rate limiting rules with independent
thresholds and time windows | `limit-count`, `limit-conn`, `ai-rate-limiting` |
+| Variable support | Use APISIX variables (`${remote_addr}`, `${http_*}`,
`${consumer_name}`, etc.) in `count`, `time_window`, and `key` fields, with
optional default values via `${var ?? default}` | `limit-count`, `limit-conn`,
`ai-rate-limiting` |
+
+Both features are fully backward compatible. Existing configurations continue
to work without modification.
+
+## Multiple Rules: Beyond Single-Threshold Rate Limiting
+
+### The Problem
+
+Consider a common requirement: limit an API to **10 requests per second** and
**500 requests per minute**. Before 3.16, you had to configure two separate
plugin instances or chain multiple routes. This was verbose, error-prone, and
hard to maintain.
+
+### The Solution
+
+The new `rules` array lets you define multiple rate limiting policies in a
single plugin configuration. Each rule operates independently with its own
counter, time window, and key.
+
+```json
+{
+ "uri": "/api/v1/*",
+ "plugins": {
+"limit-count": {
+ "rules": [
+{
+ "count": 10,
+ "time_window": 1,
+ "key": "${remote_addr}_per_second",
+ "header_prefix": "per-second"
+},
+{
+ "count": 500,
+ "time_window": 60,
+ "key": "${remote_addr}_per_minute",
+ "header_prefix": "per-minute"
+},
+{
+ "count": 1,
+ "time_window": 86400,
+ "key": "${remote_addr}_per_day",
+ "header_prefix": "per-day"
+}
+ ],
+ "rejected_code": 429
+}
+ },
+ "upstream": {
+"type": "roundrobin",
+"nodes": {
+ "127.0.0.1:1980": 1
+}
+ }
+}
+```
+
+With this configuration, APISIX enforces all three limits simultaneously. A
client hitting the per-second limit receives a `429` response with headers
indicating which limit was exceeded:
+
+```
+X-Per-Second-RateLimit-Limit: 10
+X-Per-Second-RateLimit-Remaining: 0
+X-Per-Second-RateLimit-Reset: 1
+X-Per-Minute-RateLimit-Limit: 500
+X-Per-Minute-RateLimit-Remaining: 499
+X-Per-Minute-RateLimit-Reset: 60
+```
+
+The `header_prefix` field lets clients distinguish which rule triggered the
rejection — critical for debugging and client-side retry logic.
+
+## Variable Support: Context-Aware Rate Limiting
+
+### The Problem
+
+Static rate limits assume every consumer is equal. In reality, a free-tier
user and an enterprise customer should have very different quotas. Before 3.16,
supporting this meant creating separate routes for each tier — leading to route
explosion and configuration drift.
+
+### The Solution
+
+Variable support lets you pull rate limiting parameters directly from the
request context. The `count`, `time_window`, and `key` fields now accept APISIX
variables.
+
+### Example 1: Per-Tier Rate Limiting via HTTP Header
+
+Suppose your authentication middleware injects an `X-Rate-Quota` header base
Re: [PR] blog: add article on APISIX 3.16 dynamic rate limiting [apisix-website]
Copilot commented on code in PR #2028:
URL: https://github.com/apache/apisix-website/pull/2028#discussion_r3076940162
##
blog/en/blog/2026/04/14/apisix-3.16-dynamic-rate-limiting.md:
##
@@ -0,0 +1,328 @@
+---
+title: "What's New in Apache APISIX 3.16: Dynamic Rate Limiting for Your API
Gateway"
+authors:
+ - name: "Ming Wen"
+title: "Author"
+url: "https://github.com/moonming";
+image_url: "https://github.com/moonming.png";
+keywords:
+ - Apache APISIX
+ - API Gateway
+ - Rate Limiting
+ - Dynamic Rate Limiting
+ - AI Gateway
+ - Multi-Tenant
+ - Token Budget
+description: Apache APISIX 3.16 introduces dynamic rate limiting with multiple
rules and variable support across limit-count, limit-conn, and ai-rate-limiting
plugins, enabling context-aware, per-tier, and multi-tenant rate limiting in a
single route configuration.
+tags: [Products]
+---
+
+Rate limiting is one of the most critical capabilities in any API gateway. Yet
for years, most gateways — including APISIX — have treated it as a static,
one-size-fits-all configuration: set a number, set a time window, done.
+
+In practice, real-world rate limiting is far more nuanced. A SaaS platform
needs different quotas for free and paid users. An AI gateway must enforce
token budgets that vary by model and consumer. A multi-tenant API must isolate
rate limits per tenant without duplicating routes.
+
+Apache APISIX 3.16 addresses these challenges head-on with two powerful
enhancements to the rate limiting plugins: **multiple rules** and **variable
support**. Together, they transform rate limiting from static configuration
into a dynamic, context-aware policy engine.
+
+
+
+## What Changed in APISIX 3.16
+
+APISIX 3.16 introduces two complementary features across the `limit-count`,
`limit-conn`, and `ai-rate-limiting` plugins:
+
+| Feature | Description | Supported Plugins |
+|-|-|---|
+| Multiple rules | Define an array of rate limiting rules with independent
thresholds and time windows | `limit-count`, `limit-conn`, `ai-rate-limiting` |
+| Variable support | Use APISIX variables (`${remote_addr}`, `${http_*}`,
`${consumer_name}`, etc.) in `count`, `time_window`, and `key` fields, with
optional default values via `${var ?? default}` | `limit-count`, `limit-conn`,
`ai-rate-limiting` |
+
+Both features are fully backward compatible. Existing configurations continue
to work without modification.
+
+## Multiple Rules: Beyond Single-Threshold Rate Limiting
+
+### The Problem
+
+Consider a common requirement: limit an API to **10 requests per second** and
**500 requests per minute**. Before 3.16, you had to configure two separate
plugin instances or chain multiple routes. This was verbose, error-prone, and
hard to maintain.
+
+### The Solution
+
+The new `rules` array lets you define multiple rate limiting policies in a
single plugin configuration. Each rule operates independently with its own
counter, time window, and key.
+
+```json
+{
+ "uri": "/api/v1/*",
+ "plugins": {
+"limit-count": {
+ "rules": [
+{
+ "count": 10,
+ "time_window": 1,
+ "key": "${remote_addr}_per_second",
+ "header_prefix": "per-second"
+},
+{
+ "count": 500,
+ "time_window": 60,
+ "key": "${remote_addr}_per_minute",
+ "header_prefix": "per-minute"
+},
+{
+ "count": 1,
+ "time_window": 86400,
+ "key": "${remote_addr}_per_day",
+ "header_prefix": "per-day"
+}
+ ],
+ "rejected_code": 429
+}
+ },
+ "upstream": {
+"type": "roundrobin",
+"nodes": {
+ "127.0.0.1:1980": 1
+}
+ }
+}
+```
+
+With this configuration, APISIX enforces all three limits simultaneously. A
client hitting the per-second limit receives a `429` response with headers
indicating which limit was exceeded:
+
+```
+X-Per-Second-RateLimit-Limit: 10
+X-Per-Second-RateLimit-Remaining: 0
+X-Per-Second-RateLimit-Reset: 1
+X-Per-Minute-RateLimit-Limit: 500
+X-Per-Minute-RateLimit-Remaining: 499
+X-Per-Minute-RateLimit-Reset: 60
+```
+
+The `header_prefix` field lets clients distinguish which rule triggered the
rejection — critical for debugging and client-side retry logic.
+
+## Variable Support: Context-Aware Rate Limiting
+
+### The Problem
+
+Static rate limits assume every consumer is equal. In reality, a free-tier
user and an enterprise customer should have very different quotas. Before 3.16,
supporting this meant creating separate routes for each tier — leading to route
explosion and configuration drift.
+
+### The Solution
+
+Variable support lets you pull rate limiting parameters directly from the
request context. The `count`, `time_window`, and `key` fields now accept APISIX
variables.
+
+### Example 1: Per-Tier Rate Limiting via HTTP Header
+
+Suppose your authentication middleware injects an `X-Rate-Quota` header based
