Есть LAMP сервер и на нем крутиться приложение. Приложение имеет фронтэнд и бэкэенд, последний в совю очередь оказывает высокую нагрузку на сервер в следствии чего фронтэенд немного пожтормаживает, особенно в моменты пиковой нагрзуки со стороны бекэенда приложения. В рамках одного сервера что-либо сделать уже невозможно: оптимизирован бекэнд и фрондэенд, переписаны тяжелые SQL запрос, модернизировано железо. Вопрос состоит в изменении архитектуры самого приложения. Я смотрю в сторону разнесения фронтэеда и бэкэнда на разные сервера. В таком случае бэкэнд будет работать как сервис к которому будет обращаться фронтэенд. Однако мне кажется и в такой конфигурации скорее всего бэкэнд будет подтормаживать с обработкой запросов приходящих от фронтэнда. Собственно возникает вопрос, как организовать архитектуру приложения в таком случае и есть ли смысл разнесения бекэнда и фронтэенда на разные сервера если бэкэнд останется все так же нагружынной/узкой частью всей связки? Есть ли какие-то типовые решения, может быть на других платформах?

Делай несколько бекендов. В чем сложность?

Типовая ситуация фронтенд-балансер-пачка бекендов.

Добавлено через 56 секунд
nginx, кстати, может работать на всех 3х этапах.

если не устраивает nginx, есть haproxy

Узкое место/проблема тут в том, что база очень сильно бывает загружена(сыпется туча данных туда + сложные запроса для анализа данных) + реально ли организовать фронтенд-балансер-пачка бекендов у хостинг провайдера?

кстати не только он   

Зависит от характера нагрузок

Варианты - репликация -> кластер -> переработка архитектуры
По степени возрастания нагрузки.

Простейший случай репликация - писать в одну БД, читать из нескольких других.
Если нагрузка на запись сильнее - то кластер
Если и его не хватает, то нужно пересматривать архитектуру.


Уточняй у своих провайдеров.
Hetzner, Godaddy вполне с таким справляются.

Думал об этом, в таком случае фронтэнд может работать с репликами, а бэкэнд с мастер сервером. Единственное, что тут мне не подходит это то, что бэкэнд 
вносит изменения в БД и фронтэнд так же вносит изменения в БД на основе которых работает бэкэнд. Реплика - однасторонняя связь, в моем случае
должна быть двухсторонняя синхронизация.

Есть мастер-мастер репликация, но это не слишком удобный вариант

Думаю да. Данные между серверами требуется поддерживать одинаковыми каждую секунду.

realtime приложения редко делают на пхп 

Так что скорее всего бока в ТЗ

это точно  , однако проект уже написан и теперь мне досталась уникальная возможность его поддерживать, доделывать и улучшать

Данные нужны вообще все и сразу?
Может быть подойдет горизонтальный шардинг?

Не совсем прямо моментально. Допустима задержка в 1-2 часа я удмаю. На фронтэнде пользователи добавляют/удаляют/изменяют критерии на основе которых  крутиться бэкэнд. 

ты имеешь ввиду что-то типа AWS?

highload

Aliance, дал правильную ссылку.
А имел в виду деление данных между серверами, если они не нужны все сразу.