Через какое действие она будет возникать?
Сверка по батчу утреннему? Перезапись + TL из write-model?

Хм, а как батчи связаны с идемпотентностью? Это скорее про обеспечение "как минимум раз" (что та же кафка обеспечивает без проблем).
Мы вроде про то, что вместо "exactly once" проще реализовать идемпотентность+"at least once"

Хм, а как батчи связаны с идемпотентностью? Это скорее про обеспечение "как минимум раз" (что та же кафка обеспечивает без проблем).
Мы вроде про то, что вместо "exactly once" проще реализовать идемпотентность+"at least once"

Хм, а как батчи связаны с идемпотентностью? Это скорее про обеспечение "как минимум раз" (что та же кафка обеспечивает без проблем).
Мы вроде про то, что вместо "exactly once" проще реализовать идемпотентность+"at least once"

Т.е. тут под батчем понимал фоновый процесс принудительного выравнивания (alignment) данных.

Ну это не идемпонетность, а принудительное приведение системы в консистинтное состояние. Это другой подход.

Ты можешь не реализовать идемпонетность, тогда у тебя будут биться данные. Их нужно будет выравнивать

При этом, данные могут рассинхронизироваться по-разным причинам, поэтому обеспечение идемпотентности и выравнивание данных, это разные задачи, они друг другу не противоречат.

Но если идемпонетность отсуствует, то данные точно будут дублироваться. Нужно будет не просто делать дедупликацию, но и устранять последствия такого дублирования, которые могут распространяться глубоко по бизнес-процессам и могут быть необратимыми

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

При построении таких решений возникают вопросы, в каком слое тот или иной сервис реализовать, как он должен работать, в реальном (близком к реальному) времени или в пакетном режиме, какие бд под ним лучше использовать и т.д. А ведь есть ещё и витрины и polyglot persistent.

Более-менее стало понятно, как системно строить такие решения и больше того, как увязать с продуктово-платформенным подходом.

Ага, я вот тут как раз и оказался :)
Думал, можно как-то хитро polyglot persistence обойти через свежие решения-уловки ))))

Есть же законы физики, модели данных, математика соответствующая) polyglot persistence про это ведь)

Вот зачем графовые базы нужны? Чтобы на экстремальных нагрузках выполнять специфичные для графов запросы. Потому что на средних нагрузках можно обойтись плагинами поверх других хранилищ.

Я вчера решил, что если у меня есть polyglot-решение для домена аналитики  (read model) - то почему бы не попробовать его напялить на бизнес-данные.
В прошлый раз так делал году в 2016, через это решая R&D задачу, сейчас аналогично.

Market Clock для тех, кто выбирает подходы к хранению, находясь в polyglot-ситуации

+ тема с мультимодельностью, описано хорошо у Владислава из NitrosBase:

https://github.com/vladislavgolovkov/nbdocs/blob/master/multimodelnost.md

Зечем мультимодельность? Вижу только одну причину - снижение нагрузки на эсплуатацию, то есть операционных костов.

Если говорить о MVP, то сейчас команды, например, мгновенно поднимут PG + Elastic в связке

Вот тут ответ - https://www.gartner.com/doc/reprints?id=1-24BVLCEI&ct=201007&st=sb

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

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

Или достаточной степени адекватности federation/reflection слой

Чем мультимодельность отличается от polyglot persistent? Или, например, от CQRS?