Project Architecture Planning

The need for planning

I think that I will not be mistaken if I say that the temptation to shift all my risks onto the shoulders of the service provider, completely forgetting about the project’s own architecture, is always very great. Deploy everything on one server, save on infrastructure, spend the saved budget on the promotion of the project - all this works before the project becomes visited.

Popularity for Internet projects rarely comes smoothly, usually it is an explosive increase in traffic generated by advertising companies, releases of new interesting product features. If at the time of traffic growth the architecture of your project is not ready for scaling, then you risk wasting a part of the budget for nothing. Next, we will consider options for building architecture and preparing the project for flexible horizontal scaling.

Planning

To build a fault-tolerant system, it is necessary to fully understand the process that passes the user's request before receiving a response from the server. And also, it is necessary to think in advance about the further development of the project, so that it does not turn out that it is impossible to grow due to architecture problems. Let's break the whole process into two independent parts: the client request and the processing of the client request on the application side.

Customer request

With the current architecture of the Internet, most requests from clients to end systems come from domain names. Thus, the DNS record defines the entry point for the application for the client. Using DNS records, we can add balancing user requests between several entry points to the application, which, in turn, adds a small reservation of the system by creating several A records for one domain.

Processing request

After the request has passed the entry point, its further path depends only on the logic of your application. At this stage, the fun begins. All applications are unique and it is difficult to advise anything, but after considering the development of most projects, you can still analyze this process using a general example, since the development process itself, on the whole, is the same for everyone, the only difference is in starting the application from a certain level. The higher the step with which the application begins its life, the easier it will be to maintain and scale in the future.

Development example

First, consider the simplest service scheme: content generation server + database. Usually, at the very beginning, in order to save money, everything is deployed within a single server. In principle, at the start of the application, this option may be suitable for understanding the load. Such a server can be optimized well and everything will work fine until the server resources are completely utilized. After which, one way or another, additional capacities will be required, but adding them will become an extremely non-trivial task. Someone at this step will simply put the database on a separate server (we will not talk about clustering and building a fault-tolerant database), which will free up a certain amount of resources, but in general this will not solve the problem. The next step is the creation / removal of the frontend (entry point) to a separate server, which already allows you to painlessly add additional content generation servers. At this stage, we already receive at least 3 independent servers, the resources of each of which are fully used for specialized tasks, which gives us the opportunity to more clearly determine the server configuration for each of the tasks, and it is here that we have the opportunity to optimize infrastructure costs. If necessary, we can already safely add front-end servers and add an A record for them. It is also a good idea to place balancing servers in front of the front-end, then we will get full control over the entire process of passing user requests. All further construction of the logic will be completely determined by your application. Such a scheme would look like this: we already receive at least 3 independent servers, the resources of each of which are fully used for specialized tasks, which gives us the opportunity to more clearly determine the server configuration for each of the tasks, and it is here that we have the opportunity to optimize infrastructure costs. If necessary, we can already safely add front-end servers and add an A record for them. It is also a good idea to place balancing servers in front of the front-end, then we will get full control over the entire process of passing user requests. All further construction of the logic will be completely determined by your application. Such a scheme would look like this: we already receive at least 3 independent servers, the resources of each of which are fully used for specialized tasks, which gives us the opportunity to more clearly determine the server configuration for each of the tasks, and it is here that we have the opportunity to optimize infrastructure costs. If necessary, we can already safely add front-end servers and add an A record for them. It is also a good idea to place balancing servers in front of the front-end, then we will get full control over the entire process of passing user requests. All further construction of the logic will be completely determined by your application. Such a scheme would look like this: which gives us the opportunity to more clearly determine the server configuration for each of the tasks, and it is here that we have the opportunity to optimize infrastructure costs. If necessary, we can already safely add front-end servers and add an A record for them. It is also a good idea to place balancing servers in front of the front-end, then we will get full control over the entire process of passing user requests. All further construction of the logic will be completely determined by your application. Such a scheme would look like this: which gives us the opportunity to more clearly determine the server configuration for each of the tasks, and it is here that we have the opportunity to optimize infrastructure costs. If necessary, we can already safely add front-end servers and add an A record for them. It is also a good idea to place balancing servers in front of the front-end, then we will get full control over the entire process of passing user requests. All further construction of the logic will be completely determined by your application. Such a scheme would look like this: It is also a good idea to place balancing servers in front of the front-end, then we will get full control over the entire process of passing user requests. All further construction of the logic will be completely determined by your application. Such a scheme would look like this: It is also a good idea to place balancing servers in front of the front-end, then we will get full control over the entire process of passing user requests. All further construction of the logic will be completely determined by your application. Such a scheme would look like this:

conclusions

It is necessary to plan the architecture from the very beginning of the life of the project, which in the process of development will save you a lot of time and effort. When planning the architecture of a project, attention must be paid to even the smallest details. And also it is necessary to remember the main points, namely:
1. Reservation of each project service;
2. Balancing between the front-ends;
3. Balancing between backends;
4. Clustering and separate removal of the database;

Successful implementation of your projects and flexible scaling!