Sometimes the growth rate of a project is slightly higher than the speed of optimization of a web application or the acquisition of more powerful equipment under the backend.
The simplest scheme of "parallelization" of the load is the removal of the main load on several frontend. Previously, you had to suffer (or enjoy someone as you like) with webdavs, clustered filesystems and other tricks to provide up-to-date information, this was until nginx appeared, or rather, proxy_store and proxy_cache in it.
')
In general, the scheme of work is as follows: Several frontend (cheap servers without raid and other adult intricacies) through round robin are given to clients. frontend gives off statics, proxies and gives off cached dynamics for guests and performs transparent proxying for registered users. TTX backend in this case does not matter much, the question of the correct configuration should be discussed individually. Additional caching of all that is possible on the backend is welcome.
The advantages of this approach are in the cost of this “clustering” due to the budget characteristics of the frontend. The refusal of any frontend is not critical, it is enough to raise its ip (if available) on another frontend or change the DNS configuration (which may result in unavailability for a number of users). In practice, the city portal where the video / photo storage on 4TB (occupied on the backend) on the frontend does not contain more than 300GB of what users actually request (you can clean it by atime, but considering that the frontend FS is mounted with noaime then by date of creation file). Static content on the backend is generated with a new name, modifying the file also creates a new file name so that the frontend works correctly.