When a client sends a task or request to a Node.js application, it enters a queue. Because Node.js uses a single-threaded model, requests are processed sequentially. However, to prevent bottlenecking, Node.js leverages a background C++ thread pool to handle intensive tasks.

By default, Node.js operates on a single thread. But behind the scenes, a C++ thread pool (managed by Libuv) assists by executing blocking operations. While the “Event Loop” itself is single-threaded, the overall environment is much more robust thanks to this multi-threaded pool working in the background.

Event-Driven Architecture

Event-Loop

• Event-loop is a single thread process used for executing code Non-Blocking. NodeJS was recommended if we create code, it must Non-Blocking.
• Because Event-Loop only uses single thread, we must be careful when creating blocking code, because it can slowly execute the code, they will busy manage code blocking, they didn’t have time to execute another code.
• Event-Loop the job only received and send code executing to C++ Threadpoll, so that why we must use code Non-Blocking for process blocking will do inside C++ Threadpool.
• Event-Loop will receive response from C++ threadpool sent via callback.

C++ Threadpool / Worker Threadpool

• NodeJS using C++ Threadpool for worker code execution.
• Threadpool inside NodeJS using library Libuv whereby default Libuv using 4 threads inside Threadpool, this makes we can do 4 workers blocking at one time. If we send 4 requests, they can execute parallel together, but if we send 6 requests only 4 requests will be executed, 2 requests will be waiting in Queue.
• If there is too much blocking worker, we can change the amount of thread in Libuv, if we want uses more thread, inside environment settings variable UV_THREADPOOL_SIZE by default using 4 threads, but we can change it, for example because my code blocking will use for encryption we want upgrade to 40 thread, but consider the impact will uses bigger memory.