In a multitier architecture, separate layers run on separate servers.
Problem
As the number of users rise, a single server may not be enough to run all of an application’s layers. [1] Also, it may be cheaper to use several low-end servers than buy a single high-end server to do everything at once.
Solution
A multitier architecture is an obvious strategy based on the idea of deploying each layer on separate machines. A layer that runs on its own server is a tier.
If code has clear layers, then moving layers into separate tiers should not require any redesign. Good layering typically results in small and simple interfaces between layers (i.e., a layer should expose as few functions as possible to higher layers). Network communication only requires a small interface between the layers.
Deploying code in separate tiers can also help improve layering. When layers are running in separate tiers, it is more difficult to mix layers: the physical separation helps enforce a logical separation.
Tiered deployment can also help improve the design. Having separate tiers forces developers to think in terms of layers, and makes it far more difficult to violate layering. It is more difficult to accidentally have presentation logic or persistence logic in the domain layer if they are running on physically separate machines.
Implementation
The shopping list application is converted into a three-tier architecture just by running the database on a separate server to Node.js:
A reverse proxy such as Nginx can help avoid common security issues, improve SSL/TLS performance and speed up static content (such as HTML, JavaScript and image files). Nginx is then an additional tier:
A multitier architecture makes it easier to increase the number of servers handling user requests. Nginx can be used to perform load balancing. Instead of a single server handling all incoming requests, Nginx can spread the workload across multiple servers:
The source code for the shopping list application does not require significant changes. Instead of hard-coding the database to ‘localhost’, store the database connection information (and any other server settings) in configuration files that can be easily modified.