Обновить
4
0
Михаил Селиверстов@mouser

Разработчик

Отправить сообщение
Я, возможно, не вполне понимаю вопрос. Масштабирование горизонтальное производится автоматически, средствами Azure, число инстансов сервис плана изменяется на один если нагрузка на процессор переходит пороговое значение.

Если говорить о том, каких нагрузок мы ожидаем в течение, например, ближайшего года, то это, если говорить о командах CQRS, десятки команд в секунду, вряд ли сотни.
Спасибо за развернутый комментарий. Вы правы, действительно эти вопросы не освещены в статье. Я постараюсь исправить это.

Ну и в самом CQRS сливать Event и Command в одной транзакции — это достаточно сильное искажение архитектуры. Command может быть проигнорирован, а Event обязан выполниться

Идеологически — да. Технически, event обязан выполниться, если он сохранен в write-базу. Но я согласен, что реализация с транзакцией — это скорее костыль, чем то, чем можно было бы похвастаться. Есть желание переписать всю техническую реализацию заново, с учетом полученного опыта. Но нет ресурса. Пока нет.
Нет, не рассматривал. Спасибо, ознакомлюсь!
Это я, значит, не очень понятно изобразил. Там перечеркнуто все, что в желтом прямоугольнике.

Требований по производительности формализованных нет. Заказчик маленький, команда маленькая, весь проект делается немного «на коленке».

Про железо. Сейчас все компоненты живут в одном App Service Plan в Azure и этого хватает. App Service Plan автоматически скейлится горизонтально, плюс перед/после аукционами (на данном этапе развития платформы известно, когда кто из пользователей платформы проводит аукционы) скейлится вверх/вниз.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность