rate-limiting: Redis sync should not have a `sync_rate` higher than the period
Author: jmadureiraCreated Sep 24, 2026Updated Sep 28, 2026
Is there an existing issue for this?
- I have searched the existing issues
Kong version ($ kong version)
Reproduced on Kong 3.9.x.
Current Behavior
With policy = redis and sync_rate >= period (for instance sync_rate = 1 and second = 1 ), the rate-limiting plugin won't be able to actually sync the counters between replicas of the cluster.
This happens because the plugin sets the key's TTL equal to the period so when the background sync starts the keys will have expired. The result is that the rate limit in effect is actually limit * workers * replicas.
Expected Behavior
There are a few options to consider here:
- Strict behaviour would be for the plugin to simply reject the configuration whenever
sync_rate >= period. - Issues a warning and keeps working as usual
- Fallback to the closest correct
sync_rate - Fallback to
sync_rate = -1for the needed cases (for instancesync_rate = 1andsecond = 1; minute = 1would meansync_rate = -1for the seconds buckets andsync_rate = 1for the minutes bucket)
Steps To Reproduce
- Configure the rate limiting plugin with policy
redis,sync_rate > 1and with some limit measured in seconds. - Spin up a kong running in cluster mode
- Make some requests to the cluster to be load-balanced between all replicas
Callers should be able to make more requests that the limits configured.
Anything else?
No response
Source: Kong/kong