Web-система. много вопросов (требуется мнение опытных разработчиков)

[kostenko]

Очень хотелось бы услышать мнение опытных разработчиков всяческих вэб-систем.
Проблема большой нагрузки. Руки зачесались все переделать.

Мне по опыту работы приходилось больше всего настраивать серверный софт,
лепить на коленке всякие системные мелочи на си или скриптах,
заставлять работать чужие, как-правило, php- и python-проекты.
Не так давно в течении года соорудил на php площадку для торговой системы.
В движке изначально закладывалось достаточно много интерактива, и сейчас,
когда нагрузка на вычисления растет, начинаю понимать плохую масштабируемость
всего этого хозяйства.
Внутри ничего фантастического нет, всего лишь много работы с большими массивами,
на тот момент, все можно было реализовать обычными php-скриптами, и все работало как сказка.
Только сейчас сказка начинает тормозить :)

Решил все переделать с нуля.

Площадка представляет собой большое хранилище товаров и информации "вокруг" этих товаров
(технические и физические характеристики, описания, структуру цен, мета-информацию для доставки (вес, риск и т.д.)).
Также генерируется и хранится куча логов, отчетов, транзакций и прочего.
Работают с системой только через web-морды, удаленно. Доступ поделён на несколько групп по уровням, у каждого уровня свой
интерфейс. Определенная часть функций в интерфейсе реализована с помощью jquery и используется для получения с сервера
разной real-time информации (и генерирует кучу запросов).
Система закрытая, поэтому не могу распространять всей "военной тайны" :)

Планируемая архитектура:
Фронтенды:
- сортируют запросы по типам
- отдают статику
- динамические запросы отдают на растерзание скриптам, которые "общаются" с бэкендами, и заворачивают результат в темплэйты.

Бэкенды
- на них крутится многопоточный демон, который через сокеты слушает "свои" запросы, держит связь с хранилищем
и занимается основными тяжелыми вычислениями, отдавая "сухой" результат на обработку фронтендам.

Хранилища
- скорее всего, sql-кластер

...и здесь возникла масса вопросов:
Оптимальна ли такая архитектура?
На каком языке написать ядро площадки?
Как организовать быстрый обмен данными между серверами, на которых крутятся движки?
Какими лучше средствами заворачивать выдачу движка в html на фронтендах?
В чем лучше хранить такой зоопарк данных? (сейчас это mysql+геморрой)

Решения вроде "купи еще 8 гб оперативы и не парься" не в данном случае. Я понимаю объем работы и хочу, пока есть время и возможности,
сделать взрослое решение. Основной мотив - набраться опыта и перейти на более высокий энергетический уровень...
В распоряжении имеется толковый верстальщик и 2 с++ программиста...

[Portnov]

Думается, проще всего будет реализовать обычную трёхзвенную архитектуру (сервер БД — application server — browser). Между application server и browser воткнуть nginx или что-нибудь из этой серии для отдачи статики (вариант: статику отдавать совсем с другого сервера, на котором только nginx). Можно на эту же проксю возложить обязанности по load balancing. Внутри application server-a пусть будет несколько процессов, общающихся по какому-нибудь rpc-протоколу (так что процессы могут быть запущены на одной машине, а могут на разных). Некоторые из этих процессов общаются непосредственно с внешним миром по http, остальные занимаются только бизнес-логикой.