\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 into Node.js and those are Native and PM2 cluster module.
\subsubsection{Native cluster module}
This approach is more basic way to deal with scaling the application. The 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 developers 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}
Since node is built with scalability in mind, spreading node processes across multiple machines is not much different than spreading them across multiple cores. The key difference is that in this case, communication is spread across more than one machine. To accommodate this way of communicating, another layer with a load balancer on a separate machine is introduced. This load balancer spreads the incoming requests across different machines which further delegate the requests across different cores.
Usually developing an application that works on multiple machines poses an obstacle. But, in the case of Node.js, frameworks are written in such a way that they force the developer to write the code in such a manner to comply with all the necessary requirements to make this possible.
\subsection{NoSQL databases and eventual consistency}
With the rapid development of internet computing, traditional relational databases lack the ability to manage such intensive traffic. The biggest problem they face is horizontal scaling because of strict relational structure and relatively slow read and write operations when database is running on a single machine.
Introducing Node.js as a server technology had the effect of a massive rise in popularity of NoSQL databases. The fact that NoSQL databases are mostly event-driven and asynchronous makes them very compatible with a backend technology like Node.js.
The main advantages of NoSQL databases are fast read and write operations, support for massive storage and the easily scalable architecture. On the other hand, this has some security drawbacks which are described in more detail later in this article.
\subsubsection{Immediate consistency}
Traditional relational database transactions guarantee a set of properties that are popularly addressed as ACID (Atomicity, Consistency, Isolation, Durability). These properties ensure that data retrieved from the database is completely accurate and valid at any point in time. However, fulfilling these constraints is in direct contradiction with horizontal scaling. This means that in relational databases every change must immediately be applied on all replicas.
\subsubsection{Eventual consistency}
In order to make horizontal scaling available, ACID constraints have to be loosened by introducing a different approach such as eventual consistency.
Eventual consistency, also called optimistic replication, is a model that guarantees high availability by propagating changes on horizontally scaled replicas at a certain point. This means that if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. The set of features that is guaranteed by this approach is popularly addressed as BASE (Basically Available, Soft state, Eventual consistency)\cite{wiki:eventualconsistency}.