To limit concurrency OR NOT to limit concurrency? (within a single ASP.NET request)

@tarun-lalwani make some great points in the comments

But I'll mention the solid advice to never preoptimize. A mid-range desktop today can easily handle a threadpool of 16 (which can handle hundreds of waiting tasks generally), a good server can handle a much larger thread pool than that, how much does your time cost vs the cost of a replacement or new server, probably less than 6 months, very possibly less than 3 months.

Any performance problem comes down to the bottlenecks, the system can only perform as fast as the slowest bottleneck. So improving those specific bottlenecks, in the real-world system, is how to improve performance. How to scale those groups of bottlenecks is how to improve scalability. There are still a lot of differences between desktop and server hardware, so I'll stress again that you need to see real-world not in-vitro metrics on these things before putting in weeks/months of effort into fixing a "problem" that may not be there.

GraphQL as mentioned allows you to rearrange where the bottlenecks occur, allowing you to distribute them more evenly, to better utilize the hardware you already have. Which is also true of many of the more modern design patterns.

In summary, it only makes sense to limit a process that if and when it becomes a problem.