Здравствуйте, gandjustas, Вы писали:

G>>>А в чем смысл "верно моделировать реальность"? тем более что у слов "верно" и "реальность" очень субъективное понимание?
G>>>Я думаю есть единственно верный способ моделирования — отталкиваться от конкретных решаемых задач. Если нам нужно транзакционно обновить состояние корзины с резервов на складе, то они должны быть в одной базе и работать в одной транзакции.
G>·>А откуда возникла такая задача "транзакционно обновить состояние корзины с резервов на складе"? По-моему, ты путаешь цель и средство.
G>Конкретно это из озона.
Это ты описываешь конкретное решение некой задачи. Сама задача-то в чём?

G>В целом в любой торговле со склада задача актуальна, если надо не продать больше чем есть на складе.
Для решения этой задачи нет необходимости обновлять корзину и склад в одной транзакции. Достаточно их обновить последовательно — вначале склад, потом корзину, в разных транзакциях.

G>·>Аналогия. Мне это напоминает давнишние споры cvcs vs dvcs. Ну как типа "нам нужно точно пронумеровать каждый changeset, как в svn. А вот git так не умеет, значит отстой". Вот только git точнее описывает реально происходящее при работе с исходниками, а не случайно придуманные "нам нужно". Не бывает в ральном мире точно пронумерованных changesets. Поэтому svn умер.
G>Я даже не возьмусь комментировать по пунктам этот опус. Я работал с SVN и git, и первый умер совсем по другим причинам, а не связанным с нумерованные ченджсетов.
Да не важно. Подставь любую другую очень "нужную" фичу, которая есть в svn но нет в git.
Суть моей аналогии, что твоё "нам нужно [xxx]" ты исходишь не из постановки бизнес-задачи, а из конкретного решения в виде монолитной архитектуры и гигантской всемогущей субд в виде одного процесса.

G>>>Тогда можно атомарность сделать за счет одной бд на одном сервере.
G>>>СУБД умеет обеспечивать атомарность изменений в рамках одного сервера\бд. Прям гарантировано умеет, в отличие от наколеночных поделок.
G>·>Да не важно. СУБД это просто такой готовый процесс.
G>Угу, процесс который умеет это делать, в отличие от твоего процесса, который по умолчанию не умеет и надо прям поприседать чтобы умел.
Речь о другом — процесс не один. Можно иметь две субд, в каждой свои локальные транзакции.

G>>>Как это связано? Если они все приходят в итоге на одни сервер? бд например, то задача решаема.
G>·>Мы можем попытаться их заставить ходить на один сервер, реализуя такую монолитную архитектуру. И это даже как-то будет работать. Пока этот один сервер не ляжет.
G>У OpenAI как-то не лег с их количеством клиентов и обращений.
А там тоже все ходят на один сервер с бд?

G>Если ты сделал оптимальные запросы, а сервер бд лег от нагрузки, то у тебя будет только одна проблема — куда потратить миллионы, которые ты заработал.
Он может просто лечь, и без нагрузки.

G>>>И что? Все равно потеряли.
G>>>В рамках бизес-процесса бывают шаги, где нужна транзакционно, а бывает что не нужна. Я же описывал что резервирование товаров на складе и смена статуса заказа на "зарезервирован" должны быть в одной транзакции
G>·>А как это решит твою проблему "пользователь плюет на это дело и идет в другой магазин"?
G>Этой проблемы просто не будет, мы никогда не продадим больше чем есть на складе если резервирование сделаем транзакционно.
Я не понимаю как "пользователь плюёт" соотносится с "не продадим больше".

G>·>Какую вообще проблему решает эта твоя "одна транзакция"?
G>Ту самую, которую ты непонятно как хочешь решить.
Это какую?

G>·>С таким же успехом резервировать можно в одной транзакции, а обновлять статус заказа на "зарезервирован" в другой.
G>
G>нельзя
Почему? Напомню контекст: МСА.

G>·>Вот только в этом случае транзакция резервирования выполняется в БД склада, а транзакция смены статуса в БД заказов. И эти БД могут быть физически распределены и размещены поближе к местам событий.
G>Ага, и в этом случае статус может стать "зарезервирован", а остаток на складе не уменьшится, и ты будешь разговаривать с недовольными покупателями.
Пока сервис склада не вернёт ответ "резервация прошла успешно" мы не обновляем статус заказа в сервисе заказов.

G>·>Это повод не использовать один процесс. И транзакции, если ими пользоваться, будут распределёнными. Что кошмар и ужас.
G>С распределенными транзакциями у тебя все ляжет сильно раньше, поэтому на практике под нагрузкой их не используют.
Я это собственно и сказал. Так какие транзакции ты предлагаешь использовать в случае нескольких процессов?

G>>>Так у меня большой проект. За 10 лет огого сколько всего написали.
G>·>Так и я о том же. В рамках МСА была бы группка мелких проектов, то можно было бы есть слона по частям. А сейчас ты в тупике.
G>У меня большой проект, который состоит из группы мелких проектов, которые примерно 8 лет усиленно пилили. В 2018 году взяли курс на микросервисность. Сейчас огромное количество проблем с консистентностью данных и быстродействием из-за МСА, что приходится почти целые сервисы переписывать, чтобы обеспечить надежность.
G>Я думаю за годик смогу запинать все это, чтобы модульный монолит получился.
Я не понимаю к чему этот опус. Тут я отвечал на твой вопрос: "а как изначально получилось что у двух команд разные версии?". Потому что проекты разные.