Применение CQRS & Event Sourcing в создании платформы для проведения онлайн-аукционов

[maxim_ge]

Вместо нее используется так называемая In-Memory Bus, что позволяет обрабатывать команду и события в одной транзакции и в случае неудачи откатить все целиком.

На картинке «In-Memory Bus» перечеркнуто… Непонятно, как это интерпретировать.

Было бы также интересно узнать требования по производительности (RPS) и какое «железо» под это выделяется.

[mouser]

Это я, значит, не очень понятно изобразил. Там перечеркнуто все, что в желтом прямоугольнике.

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

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

[maxim_ge]

Я так понял, что масштабирование таки производится — но под какие требования, если не секрет? Какие характеристики, скажем, потока запросов на обновление?

[mouser]

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

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

[maxim_ge]

Благодарю, то, что надо

[votez]

Вообще-то непонятно, почему было принято архитектурное решение CQRS/ES. Логики не прослеживается именно в описании выбора. Дано:
1) пришел готовый проект, который писали по CRUD.
2) Он работает плохо. Симптоматика кратко дана.
3) ?????
4) Поэтому решили делать на CQRS/ES.

Почему плохо подходит CRUD? Может, это проблема реализации, а не подхода? Как CQRS/ES была признана способной решить именно эти проблемы, помимо "поговорили с коллегами"? Что получилось сделать хорошо, помимо описанных в статье проблем? Это хорошо, что тут CQRS/ES подошел отлично, исходя из опыта проекта, но из статьи совсем не понятно, почему.
Ну и в самом CQRS сливать Event и Command в одной транзакции — это достаточно сильное искажение архитектуры. Command может быть проигнорирован, а Event обязан выполниться — это их основное отличие, диктующее способ применения.

[mouser]

Спасибо за развернутый комментарий. Вы правы, действительно эти вопросы не освещены в статье. Я постараюсь исправить это.

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

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

[oblomov86]

Если вам нужно реактивное взаимодействие с объектами в реальном времени, стоит посмотреть в сторону акторов. Например, Orleans или akka.net. Рассматривали этот вариант?

[mouser]

Нет, не рассматривал. Спасибо, ознакомлюсь!

[Dansoid]

Согласен с предыдущим постом. Orleans именно то что здесь нужно.