#15018·kong

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:

  1. Strict behaviour would be for the plugin to simply reject the configuration whenever sync_rate >= period.
  2. Issues a warning and keeps working as usual
  3. Fallback to the closest correct sync_rate
  4. Fallback to sync_rate = -1 for the needed cases (for instance sync_rate = 1 and second = 1; minute = 1 would mean sync_rate = -1 for the seconds buckets and sync_rate = 1 for the minutes bucket)

Steps To Reproduce

  1. Configure the rate limiting plugin with policy redis, sync_rate > 1 and with some limit measured in seconds.
  2. Spin up a kong running in cluster mode
  3. 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