Project Architecture Planning

Planning need

I think that I’m not mistaken if I say that the temptation to put all your risks on the shoulders of the service provider, completely forgetting about the project’s own architecture, is always very great. Expand everything on one server, save on infrastructure, spend the saved budget on the promotion of the project - it all works before the project becomes visited.

Popularity to Internet projects rarely comes systematically, usually this is the explosive growth of traffic generated by advertising companies, releases of new interesting product features. If, at the moment of traffic growth, the architecture of your project is not ready for scaling, then you risk wasting part of your budget. Next, we consider the 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 a user’s request passes 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 Internet architecture, most of the requests from clients to end systems are made using domain names. Thus, the DNS record defines the entry point for the client to the application. Using DNS records, we can add user request balancing between several entry points into the application, which, in turn, adds a small system backup 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, and all the fun begins. All applications are unique and it is difficult to advise anything, but, having considered the development of most projects, you can still analyze this process with a general example, since the development process itself is generally the same for everyone, the difference is only in launching the application from a certain level. The higher the level at which the application begins its life, the easier it will be maintained and scaled in the future.

Development example

To begin, consider the simplest scheme of the service: the server generating content + database. Usually, at the very beginning, in order to save, 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 well optimized and everything will work fine until the server resources are fully utilized. After that, 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 render the database to a separate server (we will not talk about clustering and building a fault-tolerant database), which will release a certain amount of resources, but in general this will not solve the problem. The next step is the creation / rendering of the frontend (entry point) to a separate server, which already allows you to add additional content generation servers without any serious consequences. At this stage, we already get at least 3 independent servers, the resources of each of which are fully used for specialized tasks, which allows us to more clearly define 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 frontend servers and add A record for them. It is also a good idea to host servers balancing before the frontends, then we will get full control over the entire process of passing user requests. All further construction of logic will be determined entirely by your application. Such a scheme would be as follows:

findings

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

Successful implementation of your projects and flexible scaling!