feat: Enhance `limit-count` Plugin to Support Aligned Time Windows
- Dominant language
- Lua
- Stars
- 17.1k
- Forks
- 2.9k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 63
Description
## Description
The `limit-count` plugin starts its time window based on the timestamp of the first request. This approach is problematic for quota-based use cases, especially when quotas need to align with standard periods such as calendar months.
To address this, I propose introducing a new attribute:
- **`aligned_time_window`**: A configuration option to define time intervals in named units (e.g., `"minute"`, `"hour"`, `"day"`, `"month"`, `"year"`) and automatically align them to standard boundaries.
This attribute would be mutually exclusive with the existing `time_window` attribute.
---
## Proposed Changes
### New Attribute:
1. **`aligned_time_window`**:
- **Type**: `string`
- **Accepted Values**: `"minute"`, `"hour"`, `"day"`, `"month"`, `"year"`
- **Default**: Not set
---
## Use Case
**Monthly Quota Enforcement**:
A user has a monthly quota of 10,000 requests. With the current implementation, if the first request occurs on January 15th, the quota applies from January 15th to February 14th. Instead, the quota should align with the calendar month (January 1st to January 31st) for better consistency, fairness, and integration with monitoring tools.
---
## Examples
### Aligned Window with `aligned_time_window`
```json
{
"plugins": {
"limit-count": {
"count": 10000,
"aligned_time_window": "month",
"key": "remote_addr",
"policy": "redis"
}
}
}
Contributor guide
Research direction
Start by locating the limit-count plugin and its existing time_window handling. Review how plugin configuration and the named policies enforce windows, then define the mutually exclusive aligned_time_window behavior and its minute, hour, day, month, and year boundaries. Done means aligned quotas work at standard boundaries without changing existing time_window behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- lua
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100