sethvargo / go-redisstore Goto Github PK

I noticed that if a key is getting constant Take requests, then the originally set rate limit for the key will never be overwritten, no matter a new Store was initialized with new limits. The original key should expire - not get traffic for 3 * original interval time - for the new limits to take effect. I'm wondering what's your take on this.

An example scenario:

• Service is set to rate limit requests with a 100 req /sec rate limit.
• There's a constant load on the service for key 'A'.
• The team would like to increase it to 200 req /sec, related env vars are set, service is rebooted.
• The change doesn't take effect for key 'A'.

I see there's a Set method that can be used to change the limits on the fly, but it feels like a bit of an overhead to call that for every request while we want to reset the limits only once.

I was wondering if we can make a rate limit check during Take and do a Set like action if they have been modified. This might have an unexpected side effect though if multiple versions of the service - having different rate limits - are live and constantly overwriting the rate limits during a rolling deployment.

Another idea was to expire the rate limit config (separately from the other data), so the new limits will take affect in e.g. in 3 * original interval time even if there's constant load. (For a rolling deployment it probably means 3 * original interval time after there's no old version of the service running.)

What do you think? Any other approaches you would suggest? I'm happy to contribute if there's a solution emerging.