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

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

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

G>>В рамках МСА у нас проблема, нет атомарности. Мы вызывали два сервиса в режиме "tell, don't ask", но второй вернул ошибку, а первый нет. Консистентность системы уже нарушена. Остается только вопрос можете ли вы с этим жить.
·>Это не в рамках МСА, а в реальном физическом мире не бывает атомарности. МСА это делает очевидным и заставляет выражать явно.
В рамках одного процесса вполне себе бывает.

G>>И самое главное сможете ли вы с этим жить в будущем.
·>Хошь, не хошь, а придётся.
Угу, ровно до тех пор пока не появятся требования чтобы этого не было.


G>>Сервис доставки сидит сообщение из очереди и дает сигнал курьеру приехать забрать заказ.
·>А товара на складе нет, т.к. минуту назад другой курьер забрал последнее для другого заказа.
То есть вы где-то ранее потеряли транзакционность зарезервировав товаров больше чем есть на складе.

·>И нам придётся писать извинительное письмо "счастливому" клиенту, оплатить курьеру потраченное время и бензин, откатить платёж по кредитке, оплатив banking fees.
·>Вот такой он, откат атомарной транзакции.
Тут дело не в транзакции выдачи со склада, тут вы транзакционность потеряли парой шагов бизнес-процесса ранее.


G>>Но у меня вопрос: а как изначально получилось что у двух команд разные версии? Кто-то же принял такое решение что две команды, должны независимо друг от друга что-то делать. Какая была логика в этом решении?
·>А как ты себе представляешь перевести огромную систему над которой работают десятки-сотни девов с одной версии на другую? У разных частей системы могут быть разные требования к памяти-процу-сети-диску.
Ну для команды в 25 человек я делал, ничего катастрофичного, тем более зачастую есть обратная совместимость.
Но я не знаю проблемы конкретно жабы, что там за проблема перехода с версии на версию. У меня в проекте сейчас работает C# 10-летней давности. Да, неэффективно по сравнению с текущей версией, но работает.