How to create an architecture to handle the high load of your web project?

Choosing the right architecture for your web product is a critical issue that needs to be addressed when thinking through its development. First of all, it must be scalable and withstand high loads. Especially if you are building a functional website, online booking service, or e-commerce solution.

Remember Black Fridays that are so popular with people? Did you know that sometimes sites and web applications cannot withstand such a huge influx of users and, as a result, they often lose a lot of money?

It might also annoy you when you had to wait long seconds for a web page to load or when your transaction is finally approved. As a result, you stopped doing business with a company that did not provide you with the proper level of customer service.

Slow loading of pages and incomplete loading of content, crashes, random errors, disconnection of the Internet connection are possible consequences of the lack of architecture for working with high load. This is why building a software system that can handle high loads is essential. Even if your web project is very small, at some point there may be an influx of users or the need for elastic scaling will arise.

Check out some facts about high load:

  • A high load occurs when a single physical server becomes unable to efficiently process data.

  • If one instance serves 10,000 connections at the same time, this is a high load. High load is the simultaneous service of thousands and millions of users

  • If you deploy a web solution on AWS (Amazon Web Services), Microsoft Azure or Google Cloud Platform, you are supporting a high-load architecture.

You may encounter the following problems if your web solution cannot handle high loads:

  • Slow or infinite page loading

  • Random errors

  • Lost connections to the web server

  • Incomplete content loading

  • Decreased user audience activity

  • Loss of customers

As you can see, the architecture of a project affects its success. No satisfied customers – no success and no profit. To implement scalable web applications, you need to understand the principles of developing high-performance software solutions.

Principles for Building Highly Effective Solutions

Dynamics and flexibility

You never know what exactly will happen to your project tomorrow. Perhaps some minor features of the product will start gaining popularity when no one expects it.

Or you need to add various functions. Or maybe you decide to promote your app and attract customers. Therefore, you must be able to scale elastic and handle high loads.

When developing large-scale web solutions, pay special attention to flexibility, as this will allow you to easily make changes and extensions. Flexibility, lack of upfront planning for all aspects is an essential characteristic of any fast-growing software system.

Gradual project growth

It is difficult to predict the size of the audience for years to come, so it is better to focus on scalability. The same goes for the architecture of the application. Step by step solutions are the backbone of successful software development.

If you’re launching a new product, it doesn’t make sense to immediately build an infrastructure that can handle millions of users and handle their many requests at the same time.

Use the cloud to host new projects as it lowers server costs, simplifies server management, and easily deploys applications.

In addition, many cloud hosting services offer private networking services, which allows software developers to securely use servers in the cloud and scale the system.

Scaling a web solution is a gradual process with 4 main steps:

  • Load analysis

  • Determination of areas that are mainly affected by the load

  • Transferring these areas to individual nodes and optimizing them

  • Load analysis

Developing a scalable web project architecture

In most cases, a new software solution runs on a single server that runs the web server, database, and the solution itself. You are not creating a large complex project from the beginning. Instead, focus on product scalability and choose a powerful server that can handle the high workload when needed.

This approach will help you save time and reduce development costs. Below are some ways to help you create high performance scalable web applications.

Splitting the database

Most often, the first node to be stressed is the database. Each request from a user to an application is typically 10 to 100 database queries. Moving the database to a separate server will increase its performance and reduce the negative impact on other components (PHP, Nginx etc.).

Database migration

In some cases, moving the database to another server can be a problem for a working web solution. For effective transfer, you need to do the following:

  • Use a simple solution – place an announcement of the planned work on the site and make the transfer. It is best to do this at night when user audience activity is minimal.

  • Use replication to synchronize data from one server to another. Once configured, you need to change the database IP address in the application to the new server. Then – turn off the old server.

Splitting the web server

The next step is to decouple the web server, which will leave more resources for the application by allocating it to a separate site. If we talk about the example with PHP, then you need to configure the deployment of the product both to the Nginx server and to the PHP server, which is the backend.

Then Nginx itself will serve static files, and the PHP server will be busy only with processing scripts. Nginx provides a connection to the backend by IP address:

server {

root /var/www/ruhighload;
index index.php;

location ~* .(php)$ {
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Keep in mind that if you are using file uploads, you need to set aside a separate node to store them.

Use multiple backends

When the load increases, the web application slows down. At some point, the reason will lie in the implementation itself. To avoid these kinds of problems, you should use multiple PHP backends.

When installing backends, make sure they have the same configuration. Use Nginx to load balance between them. To do this, define a list of upstream backends and use it in the configuration:

upstream backend {
server {
root / var / www / ruhighload;
index index.php;
location ~ * . (php) $ {
fastcgi_pass backend;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;

When you start using multiple backends, requests from the same user will be sent to different servers. This will require a single repository for all sessions.

You can choose Memcache for example. You should also connect the cache servers. Memcache will independently distribute the load between all servers using a constant hashing algorithm.

Task Queues and DNS Balancing

Task queues allow heavy operations to be performed asynchronously without slowing down the main application. While the queue server receives jobs from the web solution, other servers will process them. If the average number of tasks in the queue will grow, increase the number of servers for load balancing.

DNS supports round robin balancing, allowing you to specify multiple IP addresses of receiving web servers, called frontends. In this case, it is necessary to install several identical frontends so that DNS gives different IP addresses to different clients. In this way, you ensure balancing between frontends.

File storages

Uploading and processing files usually happens on the backend side. Having multiple backends is completely inconvenient and inefficient, as software engineers have to remember which backend they are uploading each file to.

Moreover, it can decrease the performance of the backend. To avoid such difficulties, you should use separate servers for downloading, storing and processing files.

This can be done as follows:

  • Define a separate subdomain for the file server.

  • Deploy Nginx to a server and a small application that can store and process files

  • Scaling by adding new servers and subdomains (e.g. images1, images2, images3, etc.)

  • Move file uploads to the client side so that the form sends a request to a specific server.

It’s no big deal to build an application that scales proportionally across servers as traffic grows. No static data, load balancing, 90% caching, reliable content delivery network, and so on – and you have an architecture ready to work with high load.

However, cost-effectiveness is key. Let’s say you have 100k users and one server. This means that to get 130 thousand of them, you need to place one more server. Seems like it’s pretty complicated, doesn’t it?

So you should take one step back and think – which part of the system is causing the problem? If it is a database, select a highly scalable database before starting your project development. Or you can use multiple databases, for example one for writing and one for reading (CQRS).

Identifying and addressing these performance issues early and without dramatically increasing infrastructure costs is good practice for dealing with the high workloads that arise.

The translation of the material was prepared as part of the launch of the course Highload Architect

We invite everyone to a free demo lesson “Choosing an architectural style (microservices, SOA and monoliths)”


Similar Posts

Leave a Reply Cancel reply