Сообщение Re[16]: Помогите правильно спроектировать микросервисное при от 02.02.2026 12:57
Изменено 02.02.2026 13:33 ·
Re[16]: Помогите правильно спроектировать микросервисное приложение
Здравствуйте, gandjustas, Вы писали:
G>Пользователь получает ошибку, пытается еще раз — сервис лежит, пользователь плюет на это дело и идет в другой магазин.
G>В рамках монолита все просто — транзакция. Она атомарная, если что откатится целиком.
Это типичная ошибка "как дОлжно" vs "как оно физически работает". Ты описываешь идеальный мир с единорогами. Всё так, так и должно работать, спору нет, я тоже за всё хорошее и против всего плохого.
А потом внезапно получается, что от момента нажатия кнопочки "хочу купить" до команды на отправку товара со склада — может пройти час, а то и неделя, а то и вообще плюнуть и уйти. Будешь держать распределённую транзакцию открытой?
G>В рамках МСА у нас проблема, нет атомарности. Мы вызывали два сервиса в режиме "tell, don't ask", но второй вернул ошибку, а первый нет. Консистентность системы уже нарушена. Остается только вопрос можете ли вы с этим жить.
Это не в рамках МСА, а в реальном физическом мире не бывает атомарности. МСА это делает очевидным и заставляет выражать явно.
G>И самое главное сможете ли вы с этим жить в будущем.
Хошь, не хошь, а придётся.
G>Но у меня вопрос: а как изначально получилось что у двух команд разные версии? Кто-то же принял такое решение что две команды, должны независимо друг от друга что-то делать. Какая была логика в этом решении?
А как ты себе представляешь перевести огромную систему над которой работают десятки-сотни девов с одной версии на другую? У разных частей системы могут быть разные требования к памяти-процу-сети-диску.
G>Пользователь получает ошибку, пытается еще раз — сервис лежит, пользователь плюет на это дело и идет в другой магазин.
G>В рамках монолита все просто — транзакция. Она атомарная, если что откатится целиком.
Это типичная ошибка "как дОлжно" vs "как оно физически работает". Ты описываешь идеальный мир с единорогами. Всё так, так и должно работать, спору нет, я тоже за всё хорошее и против всего плохого.
А потом внезапно получается, что от момента нажатия кнопочки "хочу купить" до команды на отправку товара со склада — может пройти час, а то и неделя, а то и вообще плюнуть и уйти. Будешь держать распределённую транзакцию открытой?
G>В рамках МСА у нас проблема, нет атомарности. Мы вызывали два сервиса в режиме "tell, don't ask", но второй вернул ошибку, а первый нет. Консистентность системы уже нарушена. Остается только вопрос можете ли вы с этим жить.
Это не в рамках МСА, а в реальном физическом мире не бывает атомарности. МСА это делает очевидным и заставляет выражать явно.
G>И самое главное сможете ли вы с этим жить в будущем.
Хошь, не хошь, а придётся.
G>Но у меня вопрос: а как изначально получилось что у двух команд разные версии? Кто-то же принял такое решение что две команды, должны независимо друг от друга что-то делать. Какая была логика в этом решении?
А как ты себе представляешь перевести огромную систему над которой работают десятки-сотни девов с одной версии на другую? У разных частей системы могут быть разные требования к памяти-процу-сети-диску.
Re[16]: Помогите правильно спроектировать микросервисное при
Здравствуйте, gandjustas, Вы писали:
G>Пользователь получает ошибку, пытается еще раз — сервис лежит, пользователь плюет на это дело и идет в другой магазин.
G>В рамках монолита все просто — транзакция. Она атомарная, если что откатится целиком.
Это типичная ошибка "как дОлжно" vs "как оно физически работает". Ты описываешь идеальный мир с единорогами. Всё так, так и должно работать, спору нет, я тоже за всё хорошее и против всего плохого.
А потом внезапно получается, что от момента нажатия кнопочки "хочу купить" до команды на отправку товара со склада — может пройти час, а то и неделя, а то и вообще плюнуть и уйти. Будешь держать распределённую транзакцию открытой?
G>В рамках МСА у нас проблема, нет атомарности. Мы вызывали два сервиса в режиме "tell, don't ask", но второй вернул ошибку, а первый нет. Консистентность системы уже нарушена. Остается только вопрос можете ли вы с этим жить.
Это не в рамках МСА, а в реальном физическом мире не бывает атомарности. МСА это делает очевидным и заставляет выражать явно.
G>И самое главное сможете ли вы с этим жить в будущем.
Хошь, не хошь, а придётся.
G>Сервис доставки сидит сообщение из очереди и дает сигнал курьеру приехать забрать заказ.
А товара на складе нет, т.к. минуту назад другой курьер забрал последнее.
И нам придётся писать извинительное письмо "счастливому" клиенту, оплатить курьеру потраченное время и бензин, откатить платёж по кредитке, оплатив banking fees.
Вот такой он, откат атомарной транзакции.
G>Но у меня вопрос: а как изначально получилось что у двух команд разные версии? Кто-то же принял такое решение что две команды, должны независимо друг от друга что-то делать. Какая была логика в этом решении?
А как ты себе представляешь перевести огромную систему над которой работают десятки-сотни девов с одной версии на другую? У разных частей системы могут быть разные требования к памяти-процу-сети-диску.
G>Пользователь получает ошибку, пытается еще раз — сервис лежит, пользователь плюет на это дело и идет в другой магазин.
G>В рамках монолита все просто — транзакция. Она атомарная, если что откатится целиком.
Это типичная ошибка "как дОлжно" vs "как оно физически работает". Ты описываешь идеальный мир с единорогами. Всё так, так и должно работать, спору нет, я тоже за всё хорошее и против всего плохого.
А потом внезапно получается, что от момента нажатия кнопочки "хочу купить" до команды на отправку товара со склада — может пройти час, а то и неделя, а то и вообще плюнуть и уйти. Будешь держать распределённую транзакцию открытой?
G>В рамках МСА у нас проблема, нет атомарности. Мы вызывали два сервиса в режиме "tell, don't ask", но второй вернул ошибку, а первый нет. Консистентность системы уже нарушена. Остается только вопрос можете ли вы с этим жить.
Это не в рамках МСА, а в реальном физическом мире не бывает атомарности. МСА это делает очевидным и заставляет выражать явно.
G>И самое главное сможете ли вы с этим жить в будущем.
Хошь, не хошь, а придётся.
G>Сервис доставки сидит сообщение из очереди и дает сигнал курьеру приехать забрать заказ.
А товара на складе нет, т.к. минуту назад другой курьер забрал последнее.
И нам придётся писать извинительное письмо "счастливому" клиенту, оплатить курьеру потраченное время и бензин, откатить платёж по кредитке, оплатив banking fees.
Вот такой он, откат атомарной транзакции.
G>Но у меня вопрос: а как изначально получилось что у двух команд разные версии? Кто-то же принял такое решение что две команды, должны независимо друг от друга что-то делать. Какая была логика в этом решении?
А как ты себе представляешь перевести огромную систему над которой работают десятки-сотни девов с одной версии на другую? У разных частей системы могут быть разные требования к памяти-процу-сети-диску.