Limiting requests per second does not bound concurrency, which is what exhausts connection pools

A limit of 50 requests per second says nothing about how many requests are in flight simultaneously. If downstream latency rises from 100 milliseconds to 4 seconds, 200 requests are concurrently holding threads, sockets and database connections while remaining perfectly within the rate limit, and the pool is what fails.

Little's law makes the relationship explicit: concurrency equals arrival rate multiplied by latency, so any rate-only limit implicitly assumes a latency ceiling that stops holding during exactly the incident you built the limit for. The complementary control is a bounded semaphore or queue on concurrent work, sized to the downstream resource, that sheds load immediately when full rather than queueing without limit. Deploy both, and alarm on queue depth rather than on the rate.