I wish the article talked more about why people use Redis as a rate limiter and why alternatives might be superior. Anecdotally I see the following play out repeatedly: 1) You probably already have Redis running 2) Adding a "good enough" rate limiter is easy 3) Faster solutions are usually more work to maintain given modern skillsets If you are a b2b SaaS company odds are your company will exceed 10 billion in market…
Don't use Redis as a rate limiter
11–20 of 29 posts
Re: Don't use Redis as a rate limiter
#12Decent article, with some technical misunderstandings about MULTI/EXEC, perhaps unnecessary skepticism about Lua, though I certainly do wish Redis had richer built-in functions for CAS and the like.
The URL suggests they might have a product to offer to solve the problem.
Re: Don't use Redis as a rate limiter
#13Re: Don't use Redis as a rate limiter
#14Here is an excerpt from the token bucket section:
> It seems there’s no way to do a token bucket with the main Redis primitives such as SET, EXPIRE, and INCR. It would require two variables and the client has to read one before choosing how to update the second, which would require pausing the whole database while a client carries this out. So what people do is execute code in Redis. This is done using modules or scripts. Using a module here is dubious: You’re now just loading a C program (shared library) into Redis; why not just load it into an actual computer? So let’s look at “scripts” instead. Scripts are pieces of Lua code executed in Redis.
shows brief example
> Now it’s probably time to ask ourselves why we are here. We wanted a rate limiter and now we’re learning a niche programming language just to execute some code in a database that has nothing relevant to our task but a roundabout way of storing an int into RAM. This concludes my quest to discover how or why rate limiters are implemented in Redis.
This highlights the overall technical depth of the article and should inform you of how authoritative it should be considered.
Re: Don't use Redis as a rate limiter
#15We used redis for a rate limiter for years and it never caused any issues at all. You just have to understand how redis works a little and make sure your algorithm scales. You really can't get much cheaper than token bucket.
Re: Don't use Redis as a rate limiter
#16I wish the article talked more about why people use Redis as a rate limiter and why alternatives might be superior. Anecdotally I see the following play out repeatedly: 1) You probably already have Redis running 2) Adding a "good enough" rate limiter is easy 3) Faster solutions are usually more work to maintain given modern skillsets If you are a b2b SaaS company odds are your company will exceed 10 billion in market…
The superior alternative is clearly author's startup. Who does not love 3rd party, cloud-hosted service in critical dependency chain on every page of your website?
Re: Don't use Redis as a rate limiter
#17I wish the article talked more about why people use Redis as a rate limiter and why alternatives might be superior. Anecdotally I see the following play out repeatedly: 1) You probably already have Redis running 2) Adding a "good enough" rate limiter is easy 3) Faster solutions are usually more work to maintain given modern skillsets If you are a b2b SaaS company odds are your company will exceed 10 billion in market…
Re: Don't use Redis as a rate limiter
#18I mean, Redis isn't a replacement for WAF or some other CDN-like-soak (e.g. Cloudflare). But for basic APIs on authenticated CRUD apps with even 10s of millions of DAUs (maybe 10k concurrent users) - I think it is probably fine.
If you need something more than Redis for rate limiting, you'll know it. I prefer to keep it simple at the start.
Re: Don't use Redis as a rate limiter
#19Re: Don't use Redis as a rate limiter
#20Use APISIX[0] instead.