I agree it’s less of an issue in more traditional, threaded req/reply servers. But queues can appear in a bunch of places. Like your load balancer may queue up

I agree it’s less of an issue in more traditional, threaded req/reply servers. But queues can appear in a bunch of places. Like your load balancer may queue up connections from clients and dole them out to app servers as they free up capacity. Normally the queue is emptyish, but app servers will do backpressure via blocking as needed, so the load balancer connection queue fills. In this case you probably don’t even want to add capacity (to an extent) because what’s the point if clients have timeouts. Also eventually you might need a worker pool pulling from a queue. Just guessing, because they seem to appear eventually in/near web servers. You can spin up a bajillion lambdas simultaneously like a madman if you want, but odds are there’s a resource constraint on the source and/or destination data store side at least. So again you’ve got async execution, a growing queue, and bottlenecks to think about still. But maybe with threaded code it’s like a “pit of success” for traffic shaping. You only have so many threads you can use, so you configure a pool size and think about what happens when you’re at capacity, and define some nice predictable failure behavior and test it. (As opposed to the node.js server that will handle more connections but surprise you with a weird bottleneck that you don’t handle gracefully). So then the trad server developer can go longer (or forever) without being bitten by the queues that remain elsewhere in their system.