Introduction in highload: basic principles of building IT-infrastructure

Let’s say you have a working website. The load has increased, and shared hosting can not take the load. Then you have migrated your web app on VDS, but it can not take the load too. Next, you need to do something. And what to do next is my article about.


You can not increase server resources infinitely. The only way is to break the application into its component parts and scale horizontally, step by step, increasing the performance of each individual structural component.

Step 1. Adding a reverse caching server

The first thing you can do in order to cope the increasing load is to add a caching server.

Artem Zaytsev
Evil marketer


Solution # 1 — add Varnish cache. You can deploy it on a separate host or the same one with the web server. It will be caching responses from the web server and return rendered pages. This solution is highly specialized, so it has a lot of rules for configuring. Also, Varnish can get purging requests from the backend to clean specific cache objects. So if you configure it correctly, the website changes will automatically be updated by Varnish.

An alternative solution is NGINX caching. It is not so flexible as a previous solution, but NGINX a little bit faster handles requests. So if your website consists entirely of static, rarely updated and added pages the solution is for you. In other cases, it is better using Varnish.

Cache server could help solve the problem with high load if your website consists of static pages. But the situations could be different: there’ s could be comment areas, personal accounts and services with dynamic data. In this case, a single caching server is not enough. The backend will be getting too many queries. So, the next step is to separate the application server into various parts.

Step 2. Migrating a database to a standalone server

Often the bottleneck of a web application is a database. And the first thing you can do is migrate it to a standalone server. So you would give the database more resources and could separately control the load that comes with it.

Of course, there are experienced developers who will tell that “it is better to rewrite the code” and reduce the number of queries to the database. But this decision could be not so easy and cheap, and the results of “rewriting” may not be as significant as trivial adding the resources for the database.

Step 3. Organizing object caching

Object cache is used to store the results of complex operations executing.

For example, you have a function which executes the query to the database. Instead of doing database queries, you can write the result in the cache with a key. In this case, only the first call to the function executes the query to the database, and in other cases, we will get the cached result.


Object caching can be implemented using Memcached, or, Redis, for example.

Мemcached is software which caching data in RAM. It carries out the needed function: adds, deletes, updates and retrieves objects. On the exhaustion of the memory, the old objects are automatically removed, being replaced by new.

Redis it is a complete NoSQL storage with different data types: strings, lists, sets, etc. Supports master-slave replication. So if you need a scalable solution, my advise is to pay attention to it.

Step 4. Creating a web cluster and load balancing.

The web cluster is several copies of the same application on different servers consolidated by the load balancer.


The first thing you need to do is to move all static files from the application server to a separate storage location (on Amazon S3 or a private file server).


After the moving of static files to a separate storage you get a clean application source. This application you will be copying to the new hosts for horizontal scaling.


To distribute the load between the application servers you need a load balancer. You can take a separate server for it or deploy it on the same host. Load balancers usually have a quite lightweight and don’t use a lot of resources.


I would recommend using as a load balancer HAProxy or NGINX. Choose between them according to the situation:

  • If you have a multi-piece architecture, it is necessary to have several load-balancing algorithms for different backends, or to work on various layers, so you should look in the direction of HAProxy.
  • If you don’t want to make the zoo from the services and for your task, it is sufficient to balance the load most simply, you may use NGINX.

Step 5. Database replication

Despite all previous efforts, the database still will be the weak link. To solve this issue, you may change the configuration from Standalone to Replica set.

Despite all previous efforts, the database still will be the weak link. To solve this issue, you may change the configuration from Standalone to Replica set.

The most common operation is reading. Replication will help to separate the storage into the Master database for writing and her Slave copies for reading. Thus you create the conditions for horizontal scaling out databases.

Instead of a conclusion

The recommendations above are universal in some sense but are more related to web applications, especially to popular CMS like Drupal, Joomla, WordPress etc. They will help to withstand a serious load.

However, we should not forget that the Highload is always a specific pattern and a common solution is not always applicable to the project. You may not go beyond the first step, staying on caching service. Or instead of Redis object cache, it will be more convenient to use Elasticsearch as a NoSQL store. Anything could happen. The main principle here is to find weak components and to gradually improve their performance.