Redis rate_limit with dynamic key

[webfrank]

Hi, it would be very useful to have a dynamic key for the redis rate limiter.

For example it could be used to rate limit a http server based on an header to rate limit per tenant instead of limiting every one.

Does it make sense?

[Jeffail]

Hey @webfrank, it's a bit beyond the scope of rate limits as they're often used outside of the context of a message itself. Would this be to rate limit a processor pipeline? If so we could maybe add a processor that implements the dynamic behaviour.

[webfrank]

Hi, the real use case I'm facing is to rate limit an exposed http endpoint per customer (a provided http header). With this implementation I will rate limit all customers.
Starting from redis rate limiter, using a dynamic key, I could limit by customer/header.

[webfrank]

Hi, I ended up with a resource like this:

- label: rate_limiter
  for_each:
    - redis_script:
        url: ${REDIS_URL:redis://localhost:6379/0}
        retries: 0
        retry_period: 0ms
        script: |
          local rate = redis.call("GET", KEYS[1])

          if rate ~= false and tonumber(rate) > tonumber(ARGV[1]) then
            return nil
          end

          redis.call("INCR", KEYS[1])
          redis.call("EXPIRE", KEYS[1], 59)

          return "OK"
        keys_mapping: |
          root = [
            "%s:%v".format(@tenant, now().ts_format("04"))
          ]
        args_mapping: |
          root = [
            100
          ]
    - catch:
      - log:
          message: Rate limit for ${! @tenant } [ ${! error() }]
      - mapping: |
          meta status = "429"
          root = ""
      - sync_response: {}
      - mapping: root = deleted()

@tenant is the key to rate limit for, bucket is fixed 1 minute.

[twmb]

Thanks for the discussion. As noted in the thread, a working solution using redis_script with Lua was found for per-tenant rate limiting. Rate limiters operate outside message context, making dynamic keys architecturally complex. Closing as the use case has a viable workaround. Feel free to open a new issue or PR if the workaround doesn't cover your needs.