Downsides to "constant" backoff with rate limiters?

[hibachrach]

The default rescheduling when violating a rate limit is (currently)

now + ( (random val between 0 and 1) * backoff + (num of previous times over limit) * backoff )

which is a linear back-off strategy, which will help to spread out excess load. However, if you don't care about spreading that out and simply want to satisfy the limiter's requirements (e.g. only N concurrent operations at a time), is there any reason not to do something like

now + ( (random val between 0 and 1) * backoff)

that is, a "constant" back-off (not really constant as it's still fuzzed to prevent a wall of jobs, but you get what I mean).

Presumably you'd want to increase the max reschedules if using a policy like this, but wondering if there are any other gotchas that I'm not seeing (e.g. too much stress on Redis).

[mperham]

It looks to me like your proposal does not ensure a minimum amount of time. The random number could be 0.001, leading to a millisecond-long "backoff".

[hibachrach]

that's fair, perhaps

now + ( (random val between 0 and 1) * (backoff - min_backoff) + min_backoff)