misty.cafe/mistykey
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

SkRateLimiterService revision 3: cache lockouts in memory to avoid redis calls

Browse source
This commit is contained in:
Hazelnoot 2025-03-28 11:43:30 -04:00
parent c41d617e63
commit 86e34175d3
2 changed files with 65 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

9
packages/backend/src/server/SkRateLimiterService.md
View file

@ -34,8 +34,9 @@ Header meanings and usage have been devised by adapting common patterns to work
## Performance
SkRateLimiterService makes between 1 and 4 redis transactions per rate limit check.
SkRateLimiterService makes between 0 and 4 redis transactions per rate limit check.
The first call is read-only, while the others perform at least one write operation.
No calls are made if a client has already been blocked at least once, as the block status is stored in a short-term memory cache.
Two integer keys are stored per client/subject, and both expire together after the maximum duration of the limit.
While performance has not been formally tested, it's expected that SkRateLimiterService has an impact roughly on par with the legacy RateLimiterService.
Redis memory usage should be notably lower due to the reduced number of keys and avoidance of set / array constructions.
@ -54,6 +55,12 @@ Any possible conflict would have to occur within a few-milliseconds window, whic
This error does not compound, as all further operations are relative (Increment and Add).
Thus, it's considered an acceptable tradeoff given the limitations imposed by Redis and ioredis.
In-process memory caches are used sparingly to avoid consistency problems.
Besides the role factor cache, there is one "important" cache which directly impacts limit calculations: the lockout cache.
This cache stores response data for blocked limits, preventing repeated calls to redis if a client ignores the 429 errors and continues making requests.
Consistency is guaranteed by only caching blocked limits (allowances are not cached), and by limiting cached data to the duration of the block.
This ensures that stale limit info is never used.
## Algorithm Pseudocode
The Atomic Leaky Bucket algorithm is described here, in pseudocode: