Node.js and its Single-Threaded World: A Real-World Analogy

This is a follow-up article of my previous article, "Node.js and its Single Threaded World". You may find it here: https://nitishkapur.blogspot.com/2019/01/why-is-node.html.

In the said article I had discussed the single-threaded nature of Node.js which is something different from its counterparts such as Apache or Internet Information Services server, in that the latter two are multi-threaded.

Let us now understand the concept of single-threaded and multi-threaded using a daily life analogy.  

Consider 2 boys going to a McDonalds’ restaurant. 

In a multi-threaded world, they would each go to a separate counter to order their meals. Neither of the 2 is aware of or affected by the other. Vendor 1 deals with only the 1st boy during the entirety of their conversation; the same goes for vendor 2 and the 2nd boy.

This methodology runs flawlessly as long as there are enough counters (and vendors) to service the hungry customers. When the restaurant gets harried and the customers outnumber the vendors, the service starts to slow down and the customers have to wait to make their order. While restaurants don’t worry about this and seem happy to make you queue. The same model doesn’t work with websites. If a website is slow the user is likely to leave and never return.

This is one of the objectives of installing higher RAMs in web servers, albeit they don’t require it most of the time. The system is established in a way as to be ready for enormous traffic. It’s like the restaurant appointing an extra 30 vendors and shifting to a larger area because things get hectic during the mealtime.

Now let us consider the boys ordering their favourite burgers in a single-threaded world.

Rather than sending each customer to a different counter, all the customers are handled by a single counter (vendor). A customer and a vendor only communicate when required; when the customer is ordering some food or the vendor is handing over the customer his ordered meal.

In this approach, both the boys give their orders to one vendor. But rather than dealing with one of them exclusively before the next, the vendor takes the order of the 1st boy and passes it to the kitchen, before taking the order from the 2^nd boy. When the vendor is informed that the meal has been prepared, the vendor then passes it back to the boy who ordered it. This process goes on.

Here, there is only one vendor who transacts with all of the customers. But instead of managing all the tasks (taking orders, preparing the meal, serving the meal) of all the orders by himself, the vendor hands over other chores to the “back end” employees and himself take the next order. The vendor concerns himself with just taking the orders.

With the single-threaded approach, it is vital to keep in mind that all of the users use the same central process. To keep the movement efficient one needs to make sure that no part of the code triggers a holdup, blocking another operation. An instance would be if the vendor in McDonald’s has to go to the kitchen to bring 1^st boy’s burger, the 2^nd boy would have to wait to make his order. Its counterpart in the coding world is termed as a blocking code.

So for the single-threaded methodology to work, it must be made sure that the code is non-blocking. It is taken care of by making any blocking operations run asynchronously.

To sum it all up:
1. The single vendor is the event loop.
2. The orders are the event calls.
3. The various tasks are different events.
4. The person who informs the vendor that the meal/order has been prepared is the callback function.