80/20 Of The Week … Single-threaded vs Multi-threaded Backends
- The basic idea
A backend has to handle many requests at the same time. The question is: do we give requests different threads
or do we keep one main event loop and avoid blocking it? 2) Multi-threaded style This is common in Java/Spring style backends. A request comes in, a thread from a pool handles it, and while that request is being processed, other requests can be handled by other threads. This feels natural because the code often reads top-to-bottom:
controller → service → repository → database
The upside is that blocking code is easier to reason about. The downside is that threads are not free. Too many threads can mean memory overhead, context switching, synchronization issues and more complexity. 3) Single-threaded / event-loop style This is common in Node.js. The idea is not that the whole runtime does literally everything on one physical thread forever. The idea is that JavaScript callbacks run on one main event loop thread, and I/O is handled asynchronously. That works well when the app spends a lot of time waiting on network calls, database calls, files, APIs and so on. The downside is simple: if you block the event loop with heavy CPU work, everything else waits too.
That is why Node’s official docs are very direct about not blocking the event loop. 4) Why would anyone build single-threaded? Because a lot of backend work is not CPU work. It is waiting. Waiting for:
- database responses
- API calls
- file reads
- network I/O
An event loop can handle many waiting operations efficiently because it does not need one dedicated thread per request. That is the main appeal. 5) What research says Older scalable server research often compared thread-based and event-driven models. The SEDA paper argued that thread-per-request models can hit scalability issues because of context switching, cache effects and synchronization overhead, while event-driven models avoid some of those costs. The classic C10K discussion was also about this exact kind of problem: how do servers handle huge numbers of concurrent clients efficiently? So this is not just a Java vs JavaScript debate.
It is an old server architecture tradeoff. 6) Which one is better? For I/O-heavy workloads, event-loop systems like Node can be very efficient. For CPU-heavy work, multi-threaded systems or worker-based designs often make more sense. For typical business backends, both can work well. The real question is: is your bottleneck CPU, I/O, blocking calls, database latency, or bad architecture? 7) TLDR Multi-threaded backend: many threads handle many requests Single-threaded event-loop backend: one main loop coordinates many non-blocking operations Java/Spring and Node.js are not just “fast vs slow”. They are different concurrency models with different failure modes.
