I'll separate concurrency from parallelism first, because that's where this usually goes wrong. A thread-per-request model uses OS-level parallelism: each thread has its own stack, the scheduler preempts them, and on multiple cores they genuinely run at the same time — but each thread carries memory and context-switch overhead, so thousands of them get expensive.

A single-threaded event-loop runtime gets concurrency without parallelism. async/await is sugar over promises, and a promise is a handle to work the runtime hands off — a socket read, a timer, a DB query — to the OS or a background pool. await doesn't block; it suspends the current function, yields control back to the event loop, and the loop runs other ready work while that I/O is outstanding. When the I/O completes, the continuation is queued and resumes. So one thread can have thousands of requests in flight because at any instant almost all of them are parked waiting on I/O, not computing. Callbacks are the same hand-off mechanism written inside-out — promises just flatten the nesting and give you try/catch error handling instead of an error-first argument on every call.

Where it falls apart — the honest edge: the model only wins when work is I/O-bound. A CPU-bound task (parsing a huge payload, hashing, image work) runs on the event-loop thread and there's no await point to yield at, so it blocks the loop and every other request stalls behind it. The fix is to move that off-thread — worker threads, a child process, or native async APIs. The boundary I'd flag: I can describe backpressure conceptually — a fast producer overwhelming a slow consumer needs the consumer to signal "pause" — but the exact stream-level mechanics differ per runtime and I'd verify the specific API.