This problem extends to other event-driven environments as well. When you have a thread pool it's easy to know your limit (e.g. N threads can support N concurre

This problem extends to other event-driven environments as well. When you have a thread pool it's easy to know your limit (e.g. N threads can support N concurrent requests, and N is usually a known, reasonable number), but in an event-driven environment concurrency can feel limitless. For a typical event-driven HTTP server, the default limit may simply be the operating system's file descriptor limit. You could limit fds, but to me this is crude (because you need fds for things other than incoming requests), and in some cases an fd limit isn't enough. In our case, we've built event-driven workers using ZeroMQ, where the number of peers is usually stable, but these peers may each issue a variable number of parallel requests over their ZeroMQ connections. To ensure we can still have backpressure in this situation, we have a setting to limit the number of active requests at once. The number to choose here feels a little arbitrary (as the limit is entirely enforced in-app, and it has nothing to do with hard OS limits like threads or fds), but just some number that we know the CPU can support in general.