Scaling the Application Backend
Backend is the backend area of applications, where business logic is handled and where user actions and events are handled in response to them.
Scaling the backend
The backend is responsible for everything that happens on the server side of the application. The backend is divided into a set of components, each responsible for a specific task. In this case, these components can be separated and maintained on separate physical servers. For example, one server handles the posts and comments of a website; another server handles the statistical data and advertising banners. And each server can have an individual set of settings needed for a particular component. This approach is used for the simplest scaling bacend.
In the case of horizontal scaling, we add a few more servers to the existing one. But this is not always something that can be afforded. Therefore, we have to determine when adding additional servers and dividing the backend components into them is really necessary.
When certain data actions are common to the whole backend, then there is no need to split it up. If, on the other hand, these data actions are of a different nature, then as the load on these actions grows, it is possible to separate them into independent components on separate servers. These approaches have their pros and cons. Therefore, it is necessary to look at individually which approach to choose for a particular project.
The division of the backend into several servers can become an expensive pleasure, and there are questions about the interaction of all the divided components with each other. In case of using one server there is another problem - how to process data in order to do it quickly, what to cache and when to do it, what to store and get from memory and what not.
Layered pie structure
It's best to build the backend so that it's in the form of a pie, layered. That is, as already mentioned, to divide it into separate components, a piece of each of which will be responsible for processing a certain action.
There's no need to spread the actions over the whole backend. For example, to get some data, let's say ordinary posts on the site, a user makes a request to the page. At this point, the frontend connects - a script that processes all requests and launches the core of our application. The address the user went to is checked in the routing layer, which determines what kind of page it is and whether it exists at all.
Then it is up to the part of the backend responsible for the business logic layer to check the incoming parameters, in our case, the page address. The address is queried by the layer responsible for accessing the data in the database. If there is data on the page with that address, the data layer returns all the required information, which is already displayed by the data display layer. In this way, everything is divided into certain layers, which at the right moment perform the task at hand.
This kind of pie allows you to complement and interchange components at the right moment. For example, in the layer responsible for the data you can add an additional connection and work with the second database, which may be on a different server. Here it is necessary to consider that moment, so that the code and data were as little connected.
Another important aspect of scaling the backend is caching. The cache is a place to put frequently used data, which can then be retrieved and used very quickly, without having to make repeated requests for it.
You should only cache when you really need to. In the first case, when there are clear signs that the database is not running fast enough, the data can be cached. In the second case, when there is some data that doesn't change often, you can cache it. For example, it is some counter of counting the number of views or votes of users. In any other case, it is better to make a request and get data in the usual way.
You need to be careful when working with the cache, because such an issue as cache invalidation appears.
Cache invalidation is when we have put some data in the cache, but by the time we took them out, the original data had already changed and the received information became irrelevant. In this case, the question arises: when to refresh the cache?
For example, you add posts to your blog. The list of posts must always be up to date and there's no need to cache it. But let's say some block "Subscribers to the post" or "Ratings of the post" can be cached. And here, to avoid cache invalidation, you need to check and update the cache when you request for these blocks when adding a new subscriber or evaluation.