Imagine a typical HTTP service that does async db queries. If HTTP requests are received more quickly than the db can complete queries (such as because the db disk or network is slow), the Promises will accumulate in the event loop and presumably cause memory pressure, trigger swap-hang etc. I would rather the HTTP service stop generating requests if the server cannot consume them fast enough.
As a possible solution I was thinking an "asyncLimit" property of the db context (or something else) could indicate that IncomingMessage.reader.pause() should be called. The db query would still be submitted anyway of course since you can't just drop it at that point. But after a while, pause()ing streams should throttle requests. After long enough, kernerl buffers will fill up, client buffers will fill up and clients will stop sending data. Then something may or may not call resume() depending on the state of things (DOS?).
So how would you deal with this scenario?
Of course any async calls could build-up in the event loop and cause problems so it would be nice if the solution was generic to the arguably very differnt async / await idiom. If async / await is thought of as like streaming Promises, the flow control of readable.pipe() could be inspiring.