Backend Runtime Models
Event loops, threads, workers and processes — the runtime model decides what "slow" means for your service. Taught as concurrency models rather than framework slogans.
Four ways a server serves many requests at once, and what each one makes cheap, expensive and dangerous.
One thread runs your JavaScript, a small pool runs some of the I/O, and knowing which is which explains most Node production behaviour.
One function that does not yield holds the only thread that makes progress, so every concurrent request pays for it.
Sync workers, threads, async and processes are four different services with the same source code — and the GIL explains which is which.
Running N copies of your service in one machine buys cores and isolation, and multiplies every per-process resource by N.
When a backend is infrastructure, no garbage collector and direct control of memory buy predictable tail latency — at a price paid in engineering time and safety.
A decision made once, changed rarely and paid for daily — decided by workload shape, ecosystem and who is on call, not by benchmarks.