Multi-Server

Multi-server focus only on serving dynamic media we can tweak its settings to maximize performance for that task. By allowing a second server to focus on serving static media, we can optimize it as well.

Beyond the specialization leads to optimization argument, the multi-server approach has another benefit over the single-server approach: ease of efficient scaling. Because we have separated the concerns from one another, it makes it very easy to scale efficiently by adding capacity exactly where it is needed.

With only minimal configuration file changes you could switch the simple one machine model to a many machine model. This is especially simple if the narrowest point in your pipe is serving dynamic content.

Admittedly this system does ask Nginx to perform as both a proxy and the static media server, and if serving static media requires more throughput than one machine can provide, you'll need to move to the server pool approach (which finalizes the separation of concerns).

To a certain extent, it's much easier to scale vertically (purchase a larger VPS or server) than to scale horizontally, and that should always be the first choice. However, should you reach a point where scaling vertically ceases to be cost-effective, the multi-server approach provides a tremendous amount of flexibility and allows higher gains per server due to specialization. 

Conclusion!

Multi-server approach has been very positive, even with very limited resources (256 megabytes of RAM on a VPS).

We offer “Multi-Server Architecture” Setup. In this architecture, application/web server and database server (be it mysql or postgresql or mongodb) will be installed on different nodes. As in AWS hosting, application files and webserver will be managed by aws ec2 instance and database will be managed by aws rds instance. Similarly, in GCP hosting, application files and webserver will be managed by compute engine VM instances and database will be managed by gcp cloudsql or another VM instances.