Currently, rate-limit constants are a mess. Some of them are still a little too tight, and they're scattered across the codebase (some still in endpoint classes, some in dedicated Refresh.Core classes). We could both clean them up, and make it no longer necessary for instance owners to rely on the constants we set (and therefore have to always push new releases to adjust them) by simply introducing a (or multiple as per #1099) config file which would contain the endpoint rate-limit parameters.
It'd contain a map, which maps bucket names to the bucket's parameters (time window, max requests, block duration), which we'd read into memory, and endpoint methods would simply have attributes which only contain the bucket name. The rate limiter in our rate limit service would then look up the bucket parameters from the loaded config using the endpoint attribute.
Currently, rate-limit constants are a mess. Some of them are still a little too tight, and they're scattered across the codebase (some still in endpoint classes, some in dedicated
Refresh.Coreclasses). We could both clean them up, and make it no longer necessary for instance owners to rely on the constants we set (and therefore have to always push new releases to adjust them) by simply introducing a (or multiple as per #1099) config file which would contain the endpoint rate-limit parameters.It'd contain a map, which maps bucket names to the bucket's parameters (time window, max requests, block duration), which we'd read into memory, and endpoint methods would simply have attributes which only contain the bucket name. The rate limiter in our rate limit service would then look up the bucket parameters from the loaded config using the endpoint attribute.