Don't use Redis as a rate limiter

  local current
  current = redis.call("incr",KEYS[1])
  if current == 1 then
      redis.call("expire",KEYS[1],1)
  end

There's so many valid good & serious reasons why we are so scared, so afraid as engineers. The feeling that chaos grows in around us, the fear of opening doors to complexity we might not be able to return from.

But we also let ourselves be scared of so many ghost tales. Use some Lua! Go ahead! Maybe there are places where being afraid & limiting ourselves makes sense, but for 99% of people: some 'yes we can' attitude is amazing. We are the empowered capable doers, us engineers. Let it rip!

(I do also want a society respectful & deference to the massive complexity of the universe about us. Uncertainty abounds! But it should not be a cudgel.)

The first few solutions are all fine for probably most cases. The dismissal of the fixed window solutions has no explanation behind why we don't want that.

> The first downside is a client could submit all his requests for a given second at the end of that second, and then submit all his requests for the next second at the start of that next second, which is not what we want.

I'm okay with that. My current company gives customers API limits per minute. Do you want to fill that up in ten seconds or across the full minute? Doesn't matter, we let you do it. I assume plenty of services acknowledge that this is fine for their use case too.

> We needed to use a transaction to do something that’s supposedly trivial for a given database product

What is the use of a transaction bad? It's not explained.

I've written quite a few Redis based rate limiters for services that get a good amount of traffic and I've never had an issue. I'm not writing APIs that get AWS or OpenAI levels of traffic, but most people aren't. Redis has never hiccuped on me with rate limits in a way that I've ever noticed. Plus the code was written within an hour or two each time, along with tests.

And then, as many of the other comments here have pointed out, this is from a rate limits as a service company, so that explains the empty attacks on Redis for this use case. Not to knock this product - it may be incredible for some serious rate limiting use cases, but most people using Redis for their rate limits don't have that.

I also wouldn't be surprised if having a hosted ElastiCache cluster in AWS is cheaper than their service while providing the same benefit for the majority of companies' scale, while also avoiding vendor lock in (because I can get Redis anywhere I turn). Hell, at a previous place I worked we also threw other unrelated cache data in the same ElastiCache cluster without thinking about it, because Redis is so convenient and powerful when it's appropriate.