Why Node Exists

"It's time for web servers to handle ten thousand clients simultaneously, don't you think? After all, the web is a big place now." — Dan Kegel, The C10K Problem (1999)

Node exists because of that sentence, and understanding it is the difference between using Node and knowing why anyone bothered.

In 1999 a web server handled a connection by dedicating a thread to it. The thread called read(), the operating system suspended it until bytes arrived, and it woke up to do a few microseconds of work. That model is beautifully simple and it has a hard ceiling: each thread reserves a stack — a megabyte is typical — and the kernel must switch between them. Ten thousand simultaneous connections meant ten thousand threads, ten gigabytes of reserved stack, and a scheduler spending more time switching than working. Kegel's page asked what it would take to break that ceiling, and the answer the industry converged on was non-blocking I/O with an event loop: one thread, thousands of connections, and no waiting.

That answer existed before Node. epoll, kqueue, nginx, Twisted, EventMachine — all predate it. What Ryan Dahl noticed in 2009 was subtler and is the actual reason Node won: every existing language already had a blocking I/O library, and programmers kept reaching for it. Give a Python or Java developer an event loop and they will, somewhere deep in a handler, call a function that blocks — and one blocking call in an event-loop server stalls every connection it is serving.

JavaScript was the one mainstream language with no I/O library at all. It had grown up in a browser, where every API that touches the network is already callback-based, and where blocking the thread visibly freezes the page. Its programmers were already trained. That is the bet Node made, and this chapter is about what it bought and what it costs.

The arithmetic of a thread per connection

The ceiling Kegel described is not subtle, and it is worth computing rather than asserting.

The gap is not a constant factor you could optimise away; it is structural. A thread's stack is reserved the moment the thread exists, regardless of whether it is computing or suspended on a read() — and in a web server it is overwhelmingly suspended.

Three consequences follow, and they are the whole argument for the model.

Memory is the first ceiling, not CPU. Long before the processor saturates, ten thousand threads have exhausted the address space you were willing to give them.

Context switching is the second. Each switch costs the kernel a few microseconds and evicts the CPU cache. With enough threads the machine spends its time deciding what to do rather than doing it.

Neither cost buys anything, because a suspended thread is not making progress. You are paying a megabyte to represent the fact that something has not happened yet — and a callback represents that in a few hundred bytes.

Concurrency without parallelism

The distinction people flatten is that Node is concurrent but not parallel: it interleaves many operations, it does not execute two at once. That sounds like a limitation and is the entire point.

Three sixty-millisecond waits take a little over two hundred milliseconds in sequence — the timers themselves are approximate — and about sixty concurrently, and no additional core was used. That is the shape of essentially every real Node performance win: not arithmetic done in parallel, but idle time reclaimed.

This is also the most common beginner mistake in the language, and it is worth naming now because it recurs for the rest of the volume. await inside a loop is sequential:

// Not what you want, almost always:
for (const id of ids) {
  results.push(await fetchUser(id));   // each waits for the last
}

// What you want, when the calls are independent:
const results = await Promise.all(ids.map(fetchUser));

The first version is not wrong — sometimes you need ordering, or you must not hammer a dependency with a hundred simultaneous requests, which is Part II's material. But writing it by accident, when the calls were independent all along, turns a sixty-millisecond handler into a six-second one, and it is invisible in code review because both versions read naturally.

One thread means no locks

A consequence people rarely state explicitly: because your JavaScript runs on one thread, shared mutable state needs no synchronisation. Two callbacks never execute simultaneously, so there is no interleaving to protect against.

Read that output carefully, because it makes a distinction the whole volume depends on.

There is no data race. In Go or Java, counter = before + 1 from a hundred threads would tear — the read, the add and the write can interleave mid-instruction, and Volume 17 spent a chapter on why that is undefined behaviour rather than merely a wrong number. In Node it cannot happen. Each callback runs to completion before the next begins, so every individual statement is effectively atomic and no mutex is ever required.

There is still a race condition. Every await is a point where your function suspends and other code runs. The value read before the await may be stale by the time you write it back. That is the check-then-act bug from Part V of the Go volume, arriving in a language that cannot have data races — which is exactly why it surprises people.

The rule worth internalising now: await is a yield point, and you must re-check anything you read across one. Not because another thread might change it, but because another callback certainly might.

What blocking actually does

The cost of the bet is concentrated in one failure, and it deserves to be measured rather than described.

The second timer asked for twenty milliseconds and got a hundred and fifty, because the event loop cannot service anything while your synchronous code is running. Substitute a real workload for burnCpu and the sentence becomes the operational reality: a synchronous stretch in one request is added latency for every other request in flight.

This is the model's genuine weakness and the honest answer to "when should I not use Node":

CPU-bound work. Image processing, video transcoding, cryptographic key derivation, large in-memory sorts. One thread is one thread, and no amount of async makes computation concurrent.

Accidentally synchronous work, which is more common and worse because nobody chose it. JSON.parse on a large payload, a synchronous file read, bcrypt at a high cost factor on the main thread, a regular expression that backtracks catastrophically on hostile input — that last one is a denial-of-service vector, not just a slowdown.

Node's answers are worker threads for genuine CPU work, a queue and a separate process for heavy jobs, and native addons for the hot path. All three are Part VII. What matters at this stage is the diagnostic instinct: when a Node service is slow for everyone at once, look for one thing that is slow for one person.

What the runtime is actually made of

"Node is JavaScript on the server" is true and hides the interesting part. Node is two large C++ projects with your JavaScript sitting on top.

V8 is Chrome's JavaScript engine: it parses, optimises and executes your code, and it owns the heap and the garbage collector. It knows nothing about files, sockets or timers — V8 in isolation cannot open anything.

libuv is the event loop and the I/O layer, written for Node and now used well beyond it. It wraps the platform's non-blocking primitives — epoll on Linux, kqueue on macOS, IOCP on Windows — behind one interface, and it maintains the thread pool that handles work the OS cannot do without blocking.

That last point is the one that corrects a common half-truth:

Two things in that table are worth carrying forward.

Network I/O uses no thread at all. This is why Node scales to tens of thousands of sockets: the kernel notifies the loop when a socket is readable, and nothing is dedicated to waiting. It is the whole answer to Kegel's question.

File and DNS I/O do use threads, because most operating systems offer no genuinely asynchronous file API. libuv fakes it with a pool of four by default, which means four concurrent file operations saturate it and the fifth queues — a real bottleneck in file-heavy services, and one that surprises people who believe every async call is free.

The JavaScript you write sits above all of this and sees one consistent story: you call something, you get a promise or a callback, and the loop delivers the result when it is ready. The next chapter is about the machinery that does the delivering.

Common Mistakes

1. await inside a loop for independent work. Each iteration waits for the last, turning a 60 ms handler into a 6 s one. Use Promise.all when the calls do not depend on each other.

2. Believing single-threaded means no concurrency bugs. There are no data races, but every await is a yield point, so read-await-write is still a race condition.

3. Confusing concurrency with parallelism. Node overlaps waiting; it does not execute two pieces of your JavaScript at once. Nothing computes faster.

4. CPU-bound work on the main thread. Image processing, key derivation, large sorts. One thread is one thread — use a worker, a queue, or a different runtime.

5. Accidentally synchronous work. A big JSON.parse, a sync file read, a backtracking regex. Correct code, passing tests, and the whole server stalls.

6. Thinking "single-threaded" describes the runtime. Your JavaScript is single-threaded; libuv runs a thread pool, and file, DNS, crypto and zlib work all use it.

7. Assuming every async call is free. The default thread pool is four, so the fifth concurrent file read queues even though your code never blocks.

8. No event-loop lag metric. It is the one measurement that distinguishes "a dependency is slow" from "we are blocking" — opposite problems, opposite fixes.

9. Choosing Node for the wrong workload. The model wins on waiting and loses on computing. Ask which one the service actually does.

10. Treating the blocking risk as theoretical. A catastrophic-backtracking regex on user input is a denial-of-service vector, not a performance note.

Interview Corner

Hands-on

Summary

• Node exists to answer the C10K problem: a thread per connection reserves a megabyte whether it is working or waiting, and web servers overwhelmingly wait.
• The bet was JavaScript specifically, because it was the one mainstream language with no blocking I/O library for programmers to reach for by habit.
• Concurrency, not parallelism. Node overlaps waiting; it never runs two pieces of your JavaScript at once, and nothing computes faster.
• await in a loop is sequential. For independent work that is the commonest accidental slowdown in the language; Promise.all is the fix.
• One thread means no data races and no mutexes — two callbacks never run at the same instant, so every statement is effectively atomic.
• But await is a yield point, so read-await-write is still a race condition. Re-check anything you read across one.
• "Single-threaded" describes your JavaScript, not the runtime. libuv keeps a thread pool — four by default — for file, DNS, crypto and zlib work.
• Network I/O uses no thread at all, which is what the whole scaling story actually rests on.
• Blocking is the cost of the bet. A synchronous stretch in one request is added latency for every request in flight.
• Event loop lag is the metric that proves it — near zero when healthy, spiking to the length of the synchronous work when blocked.

This chapter treated the event loop as a black box that "delivers results when they are ready". The next opens it. Node's loop is not one queue but a sequence of phases — timers, pending callbacks, poll, check, close — each with its own queue, and the order they run in explains behaviour that otherwise looks arbitrary: why a setTimeout(fn, 0) sometimes runs before an I/O callback and sometimes after, and why setImmediate exists at all when a zero-delay timer looks like the same thing.