Why you shouldn't use Redis as a rate limiter

>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.

I've found it quite useful to have a central slice of RAM that different processes, including ones running on different machines, can execute scripts against over the network.

If you have Web servers running across different machines, you don't want rate limiter state to be local to those machines. A client shouldn't be able to make extra requests because the load balancer sends its traffic to a different machine. So that necessitates a central slice of RAM, accessed over the network.

Maybe a dedicated rate limiting service? It might perform better, but I've used redis token bucket rate limiting, implemented via a Lua script, at scale without much issue. And what about the foundational things redis provides, like persistence and failover? Or what if you don't just want rate limiting; you want (for example) mutexes[0] too? You can implement all of that and more, of course, and I'm not saying that's always a bad idea, but at some point you may risk running into Greenspun's Tenth Rule (but for redis instead of Common Lisp). There's something to be said for making the central-slice-of-networked-RAM part a platform, which you can build on with scripts to do whatever you need.

[0] https://redis.io/docs/latest/develop/clients/patterns/distri...

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 cap looong before Redis rate limiting is a meaningful bottleneck.

This blog is kinda strange because it presents a working solution, and then immediately dismisses it with:

> 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.

If you this seems like unfair criticism, read the blog title. It is "Ratelimitly’s Official Engineering Blog". What you are supposed to do is (1) get scared about complexity of the task (2) contact author's startup and buy rate-limiting-as-a-service (the pricing is "contact us" BTW)

At my previous employer, we used Redis for publicly-documented rate limits, but we applied them after our rate limiting infrastructure already evaluated defensive infrastructure-oriented rate limits.

We generally found that this worked out fine. Customer-facing limits were numbers measured in hours or days; infra limits were measured in seconds or minutes.

Certainly you wouldn’t want to rely on a central db for infra-oriented rate limiting, in any case.

Decent 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.