The Myth of Node.js as a Single-Threaded Server, and Handling Large-Scale Data

Node.js runs JavaScript execution and the event loop on a single main thread, but offloads long-running I/O work to libuv and worker threads. So from a developer's perspective it looks single-threaded, while the actual architecture actively leverages multi-threaded elements.

Conversely, CPU-intensive work directly blocks the main thread. When tasks like image/video encoding, large-scale JSON parsing, sorting, or encryption come in, other requests get held up, and Node.js's weakness becomes clear.

As a real-world case, the article introduces the 6 billion-record migration of NaverPay's timeline server. In the process of Node.js parsing and transforming data pulled from Hive into JSON before inserting it into MongoDB, the bottleneck turned out to be not MongoDB but Node.js's parsing stage. Based on kubectl top pods, the Node.js Pod used around 1020–1030m CPU, nearly saturating a single core, and running it on one machine was calculated to take 25 days.

The solution was scale-out. By spinning up multiple Node.js Pods in k8s to run in parallel, the bottleneck shifted from Node.js to MongoDB, bringing the large-scale migration down to a manageable level. This leads to the conclusion that for general API servers too, thanks to its light memory usage and container-friendly structure, Node.js is a good option that can be split and scaled to fit the purpose.

The key point is not to judge Node.js simply by "single-threaded or not," but to understand together the simplicity of the main thread and the asynchronous, scale-out structure supporting it behind the scenes. From that perspective, Node.js's "philosophy designed to behave like a single thread" actually becomes a strength in practice.