Игорь Воротнёв

Теоретически конечно могут возникать ситуации, когда и бек, и фронт, лезут редактировать одно и то же место, в одном и том же файле, плюс-минус в одно и то же время. Что может приводить к merge conflicts.

Но, во-первых, такое должно происходить крайне редко. Во-вторых, если это происходит, то это вопрос не совсем корректных процессов или архитектуры. В третьих, такие конфликты легко резолвятся тимлидом.

Поэтому, лично я не вижу никакой проблемы в том, что работа идет в feature branches, каждый делает свою часть, а потом это все мерджится.

А где это вы ищете?
Да, мелких заказов по CMS заметно много, и они часто забивают ленту обновлений. Фильтры настройте. Работы хватает во всех нишах.

4 млн одновременно?
4 млн в день?
4 млн в месяц?

4 млн по 1 просмотру?
4 млн по 1000 просмотров, включая страницы с высокой нагрузкой на процессор / память / диск?

4 млн с 95% запросами в бд на чтение?
4 млн с 50% запросами в бд на запись?

...

Понимаете, куда я клоню?

Вообще, то что вы спрашиваете, называется load balancing, или балансировщик нагрузки. Гуглите, изучайте основы и принципы этой архитектуры. Когда освоитесь в теме, сами поймете что делать. Возникнут более точные вопросы по ходу - милости просим.

Если на все это нет времени, наймите специалиста, который задаст вам вагон вопросов и построит подходящее решение на базе того же AWS.

PS: 4 млн уников, если считать "в месяц", это не огромное число. Много, да. Но далеко не огромное и обслуживается достаточно легко.

UPDATE: +1 к ссылке на ruhighload.com от Bowen