Синхронизация данных на стороне запроса в CQRS — не будет ли конфликтов?

все зависит от того, как вы спроектировали инфраструктуру. Строго говоря, CQRS сам по себе ничего не говорит о том, как обновляются модели Query. Использование событий — это лишь один из вариантов, который у вас есть. CQRS также ничего не говорит о разрешении конфликтов. Это всего лишь архитектурный паттерн, который оставляет вам больше возможностей и возможностей для решения таких задач, как параллелизм. В «обычных» архитектурах, таких как многоуровневая архитектура, у вас часто вообще нет этих опций.

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

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

Однако будьте осторожны и не оптимизируйте преждевременно. Не увеличивайте масштаб, пока не получите цифры, подтверждающие, что это поможет в вашем конкретном случае. Архитектуры, основанные на CQRS, позволяют вам сделать большой выбор. Все, что вам нужно сделать, это сделать правильный выбор в нужное время.

До сих пор в приложении, с которым я работаю, я не сталкивался с ситуациями, когда модель запроса была узким местом. Некоторые из этих приложений производят более 100 миллионов событий в день.