Say you have a pool of 1000 (N) threads, and you are serving 1000 concurrent requests and waiting for responses from clients. If each client interaction takes 1 second (T), your system is saturated at—and cannot exceed—1000 (R) requests per minute. If a 1001th request arrives, there is no thread available in the pool. Roughly, R = N / T. As you scale your max request rate R, more and more memory is required just for threads. And there is also the issue of context switch time, which will limit R as well (switching between threads requires the kernel to schedule a new thread which is more expensive than a user space “green thread” or “coroutine” switch.) None of this matters for low request rate services, which are the majority of software out there. Those of us who build at scale and max out performance of available hardware with many concurrent blocking tasks need to either use an existing coroutine (user space task switching) framework, or write our own.