for a web apps concurrency is usually abstracted away into the database. concurrency within the web worker is usually boiled down to parallel access to separate

for a web apps concurrency is usually abstracted away into the database. concurrency within the web worker is usually boiled down to parallel access to separate blocking resources that don't interfere with each other. it's quite rare to see web worker sharing some state between requests (because as soon as you hit multiple workers you need to care about session stickiness, not to mention the fact that state itself becomes sharded, so not very useful for most purposes) or request having to do enough heavy lifting to require parallelisation. it's a capacity planning issue which is somewhat related to how you parallelize the work but in the end, roughly `work per request W * number of requests N must be <= worker capacity C * number of workers M` or you will have a growing backlog. i imagine sync vs async resource access affects request timing variance more than it affects the median when the system is saturated but that depends on how resources respond to contention. so to answer your question - there is no general rule, every system has it's own scaling characteristics, but simpler system is better than complicated one so start with sequential access and measure a lot as you change it.