технически они ничего не меняют, одна рид модель может строиться на основе данных двух агрегатов.

Логика тут такая - рид модель - она для пользователей. Каких-то внешних экторов. Для них принятие решение на основании устаревших данных (даже если речь идет о 100 милисекундах) это норма ибо законы физики. Потому один источник данных или несколько не важно, важно только что бы модель обновилась по итогу.

Спасибо!!!!

У меня есть странный кейс связанный с задержками обновлений рид-модели и прочего, когда мне нужно отправить сообщение по веб сокетам клиентам с полями из этой рид модели, а она могла еще не обновится при формировании сообщения. Например в мессенжере создается диалог и в уведомлении участникам нужно класть информацию об этом диалоге в том числе кол-во участников. Как отправлять точно обновленные данные? Я пока думаю только о версии в евенте сущности и о версии рид модели, и если при формировании события рид модель не достигла этой версии, ждать немного и пробовать заного.

Вроде норм, т.к большой лаг между рид моделью и агрегатом будет редко, но мало ли есть более хорошие идеи. Мб просто перестать слать клиентам столько инфы?)

А почему не воспринимать веб сокеты как отдельную рид модель
зачем какую то прокси вставлять между сокетами и событиями?

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

Самая главная проблема я думаю тут - это то, что в основной бд есть не все данные(каунтеры, статусы прочтений и т.д храняться в редисе), плюс надо обогощять данными из других модулей

зачем в веб сокетах присылать то что не изменилось?
фронты на столько не але что не могут в паршиал апдейты?

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

В конце концов написать такую штуку на JS дело 2 дней максимум даже не фронтендеру

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

Да они могут сходить сделать кверю на этого чувака, но как по мне это лишнее

чаще всего да)

ну по айдишнику недостающию информацию подтянуть не высшей математики задача

я в таких случая иду и сам им пишу
ну ибо это проще чем костыли городить

Им потом даже стыдно бывает становится

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

в таком слуяае обычно решается передачей версии поста
А фронты просто должны будут проверить что версия не меньше

Спасибо, я думаю попытаюсь как-то постепенно упроситить пэйлоад в уведомлениях, а там где это нельзя сделать сделаю версию и пусть фронты сами чекают. На бэкэ не буду чекать версию, т.к тогда реалтайм превратится в не очень реалтайм.

Думаете нас тут нет, а мы среди вас 👅

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