\section{Scalability comparison}
In this part we will go into detail about differences in
technologies that affect scalability and describe the key features
of Node that make it easily scalable.
\subsection{Vertical and horizontal scaling}
In terms of scaling applications we encounter two different approaches, the first being vertical and the other being horizontal scaling.
\subsubsection{Vertical scaling}
Vertical scaling implies upgrading the machine on which the server is running by increasing its memory or CPU power. The problem with this is that it is limited and it is not very cost effective past a certain point.
\subsubsection{Horizontal scaling}
Horizontal scaling implies introducing additional machines on which the server is running. This approach is more effective because the performance gain is linear with the cost. However, the process is more complex and error prone.
\subsection{Reasons behind the differences}
When other popular alternatives were being designed, like PHP or Python-web, scalability was not as much of a need. In the early age of web development, the client requests were not that heavy and frequent, so the architecture did not need to be designed for massive horizontal scaling. On the other hand, because of today's requirements, Node.js was designed so it can be easily scaled from the very beginning.
\subsection{“Horizontal scaling” on a single machine}
Having in mind that Node.js is designed to run on a single thread, the only way to utilize the multi-core architecture is to scale horizontally on a single machine. This feature is built into Node.js so that developers can easily make better performing applications without having to deal with the complexities of horizontal scaling. There are two approaches to easily spread work over processor cores that are built in Node.js and that include Native and PM2 cluster module.
\subsubsection{Native cluster module}
This approach is more basic way to deal with scaling the application. Web server starts as a single process, later called the master, and it is responsible for spawning child processes, called workers, one for each core. The incoming requests are delegated to worker processes and they become responsible for returning the response back to client.
The main drawback of this approach is having different types of processes with which the developer has to deal manually.
\subsubsection{PM2 cluster module}
This approach is a bit more advanced way to deal with scaling the application. PM2 is a process manager that lets developer scale worker processes across all processor cores without worrying about spawning them. This way, the application is organized in more homogeneous way and it can be developed the same way as it was designed for single core.
\subsection{Node clustering}

\subsection{NoSQL databases and eventual consistency}
With the rapid development of internet computing, tradition relational databases lack the ability to manage such an intensive traffic. The biggest problem it faces is horizontal scaling because of strict relational structure and relatively slow read and write operations when database is running on a single machine.
Including Node.js as server technology had the effect of massive rise in popularity of NoSQL database. The fact that NoSQL databases are mostly event-driven and asynchronous makes them very compatible with a backend technology like Node.js is. This sentence just adds a few words to our beloved lovely c'mon count piece of shit damn son.