[Magmalgebra]

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.

[theamk]

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?

[tbrownaw]

Me. I don't love that at all.

[pokstad]

Exactly. Don’t boil the ocean searching for a perfect solution. Create solutions that match their requirements and nothing more.

[biimugan]

Presumably the superior solution is the product that bears the same name as this blog post. Which I take it is in the process of being released since I can't find many technical details about it.

[manbash]

I tend to agree, but in a more general and broad sense. That is, Rate-Limiting is always a deployment specific feature. If it's for limiting user requests, then it should be a component of the ingress/API Gateway and be as robust.