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

Ну то есть ты как бы можешь и без ивент сурсинга это делать, просто не так удобно.

На тему молнеиносный рантайм - это к вопрос о том что проектируем мол систему так что бы пользователю не надо было ждать завершения операции. Это вот можешь Уди Дахана на тему CQRS почитать посмотреть

ну и

> Как синхронизировать?

Хочешь "молнеиносный" - не синхронизировать.

Как там было, авайлабилити - консистенс - скорость, дайте два?
Ну понял, спасибо за мнение

ну тут скорее значение консистентности сильно преувеличено.

eventual consistency все еще консистентно

Да но может быть кейс когда там уже прилетело, но до другой ещё не долетело, и всё уже другое. Так что :/

так что CQRS, проектирование модели предметной области с позиции "разбираемся почему бизнес транзакция может не пройти и пытаемся придумать как поменять процесс так что бы в 99.99% ситуаций по бизнесовым причинам все было ок + компенсационные действия для оставнегося одного

ищем где происходит колаборация, смотрим как минимизировать импакт, кто проиграет и как...

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

пример что я имею ввиду

- водители убера хотят видеть куда поедут, но эта инфа позволяет им отказываться от заказов и в итоге эффективность системы снижается. А потому штрафы за отмену + не показывать + фичи в стиле "водитель указывает желаемые направления и может это делать 2 раза в день". Это не то что изначально хотели но это то что эффективно работает.
- врачи хотят видеть с какими пациентами им сча надо работать. Но это для случаев аля консультации по ковиду не эффективно так как увеличивает wait time. Решение - общая очередь пациентов и раскидывание нагрузки по врачам - врачам не нравится но это эффективно.

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

поищи по чату ADSD и смотри. Я не оч понимаю что ты говоришь если честно. Оч общие фразы

Нашёл, thanks

короч - ивент сурсинг это про то как ты работаешь со временем. У тебя тут есть как бы несколько стратегий. ты можешь как гугл вложиться в мега дорогую и сложную инфраструктуру которая позволяет тебе время синхроинизировать с дикой точностью и за счет этого мутить всякие репликации надежно. А можешь в целом делать допущение что "текущего времени нет - два наблюдателя никогда не договорятся что есть сейчас" и строить модели на основе этого. Тут вот event sourcing хорошо ложится.

Что выбирать - каждый решает по задаче. Универсальных решений нет

когда у тебя бизнес логика не сильно завязана на вопрос "а когда это произошло" то сильно бенифитов ты не увидишь. Ну или просто когда объем ивентов не оч большой.

это все хорошо рассматривать на экстримальных примерах что бы лучше понимать какие варианты хорошо ложатся на твою проблема у какие нет.

аля... если ты делаешь систему и там скажем 10К юзеров чет делают одновременно (хотят купить одну видеокарту, если про сегодняшние реалии например) и ты получишь конфликт с вероятностью в 99% - то тут надо пересматривать модель взаимодействия. Аля ты не сразу покупаешь а скорее оставляешь заявку а система сама разрулит кто купил. В этом случае как бы не все получат по итогу и придется возвращать деньги (просто зарелизить холд) но с другой стороны ты знаешь что если операция покупки будет не 100 милисекунд а несколько секунд из-за локов и будут постоянно ошибки и конфликты - вероятность спонтанной покупки снижается и "бизнес теряет деньги"

Можно пошутить, что пользователи не создадут конфликт, так как видеокарт нет.

они как раз есть, просто спрос сильно привышает предложение