Здравствуйте, boot, Вы писали:

B>Такие "мелочи" многое определяют в архитектуре. Поди еще серверная часть распределенная, сервер сессий на одной машине, а СУБД не одна, да еще и на другой машине? Поди еще и тяжелые процедуры на сервере или в СУБД имеют место быть? Я не стал бы забивать на эти "мелочи" в самом начале, в конечном итоге все определяет скорость, а скорость это цифра, значит необходимы расчеты, иначе, методом тыка, дольше будет разработка. Ваша схема недоступна для критики, мало сведений. Тут хорошо бы еще знать как много запросов к СУБД, и сколько из них повторяется. Возможно будет полезна кеширующая прослойка в памяти. Чесслово не знаю как Вам лучше сделать, но детали интересны. Конкурентов много опережает?

Более того, хотелось бы изначально заложить в архитектуру и распределенность самого сервиса, т.е. сервис может находиться на нескольких серверах. но боюсь, что "малой кровью" для обеспечения такой архитектуры не отделаться, а необходимости в этом пока не вижу. Тяжелые места на сервере имеют место быть, на СУБД вряд ли (по-крайней мере я буду максимально стараться всю тяжесть бизнес-логики переносить на сам сервис и ХП использовать по минимуму).
Нагрузка средняя — обычная ERP система, до нескольких десятков пользователей. Ожидаются относительно тяжелые вычисления в некоторых модулях, но как я писал, вся нагрузка будет приходиться на сервисы с бизнес-логикой. Предполагаю, что в большинстве своем получится построить запросы так чтобы они откешировались СУБД (на данный момент планирую SQL Server). Разнообразность предполагаю построить через параметры запросов. Насчет кеширующей прослойки я и сам думал , но все взвесил и необходимости в ней не вижу.
Вроде у себя сформировал полностью целостностное представление всей архитектуры, но боюсь что-то упустить или выбрать неверное архитектурное решение, т.к. от этого зависит мое будущее в данной компании (а возможно и в глобальном смысле тоже )
Что Вы имели в виду под вопросом: "Конкурентов много опережает?"?