The basic premise is not do do req/s limiting but rather concurrency limiting which results in req/s limiting by itself.
Concurrency limiting is rather simple and doesn't require a lot of code complexity.
If however you are trying to limit client(s) because the service is an authentication gateway for instance, then you want to limit user/pass requests to X number then concurrency limiting isn't a good way to do that.
So you may need both, depending on your use-cases, so it's not a one-size fits all solution.
Wouldn't that just be rate limiting by client IP though?
Modern distributed systems are simply too fast and users are too dumb with picking passwords to allow unlimited password attempts.
After X attempts via the same IP, you can block/ban that IP via a FW rule/etc for say 5 mins. or 30m, or whatever.
It all depends on your security posture, you could go crazy and actually lock the account after 3 failures, but then you hand bad people a free DDOS... so you have to be careful about doing that.. But you could soft-lock and require a correct password and an email address verification after X failed attempts(i.e. correct login, plus they have to click a link in an email).
Anyways, see what I'm saying here? Authentication access is something you really want to get right, and it's a complicated topic.
This won't defeat an adversary with a botnet.