[eurleif]

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