Доклад: Проектируем Event Driven-систему с DDD и Event Storming / Кирилл Ветчинкин (microarch.ru)

Это взгляд на современный подход к построению масштабируемых и высоконагруженных систем. В докладе обсудим ключевые принципы асинхронной архитектуры. Рассмотрим, как события, очереди и сообщения помогают улучшить производительность и управляемость распределённых систем.
Презентацияя drive.google.c...
Понравилось видео и хочешь узнать что-то еще про Podlodka Java Crew? Забирай весь плейлист на podlodka.io/cr... или покупай годовой доступ ко всей Библиотеке контента.

[@sergeyz.5845]

такая четкая речь и способность складывать слова в предложения сегодня большая редкость среди IT докладчиков

[@IuriiRybakov]

Отличный доклад, спасибо.

[@СтрогановаНика]

Прекрасный доклад!

[@dragvs]

Качественный и наглядный доклад. Еще стоит таки отмечать проблемы такого подхода прямо в докладе. Задали правильный вопрос что асинхронка вызывает eventual consistency и вы должны так же согласовывать допустимость этого со стейкхолдерами либо учитывать это. Про проблемы можно отослать к классику - Martin Fowler.

[@alexandr-popov]

Микросервисы и их распределенность уже привносят eventual consistency, если вы считаете, что у вас там может быть что-то согласовано в реальном времени, то я вас разочарую - вы обманываете себя Если заменить взаимодействие async на sync вы просто добавите необходимость ответа "здесь и сейчас в рамках таймаута", но никак не избавитесь от сетевого вызова, который по своей сути под капотом асинхронный и во вы просто компенсируете это показом пользователю спиннера на вксь экран на 5-10 секунд и снижаете доступность отдавая 500 когда хотябы один сервис не отвечает по цепочке "синхронных вызовов", при этом состояние всп равно вполе может стать неконсистентным на какое-то время

[@dragvs]

@@alexandr-popov в целом то оно так, но это не отменяет того факта, что существуют системы с требованиями по strong consistency. Не является event-driven подход серебряной пулей от всех проблем, у него есть свои ограничения. По сути без обозначения ограничений и потенциальных проблем доклад является неполным т.к. докладчик неявно предлагает слушателям проверить их на собственной шкуре. Где-то может быть нормальным показать спиннер на 10 секунд или вернуть 500. В блокчейне народ по полчаса транзакции может ждать почти без гарантий выполнения и ничего.

[@akitmentorconsultant4696]

Ну вот есть поле Price, и есть 600 сервисов куда оно должно реплицироваться. Теперь мне нужно добавить поле currency к этому прайс. То есть получается мне теперь для всех сервисов нужно написать как минимум миграцию для 600 баз данных а как максимум ещё и подправить кодогенерацию где-нибудь в entity framework. А ещё нужно а ещё нужно в каждой базе при миграции установить значение currency для каждого значения прайс. И это 100% будет делаться синхронно хоть и один раз. А так как остановить все сервисы при миграции невозможно, то появляется конкуренция за обновление записи с price и currency между транзакции из миграции и транзакциями которые идут из очереди в реплицируемые базы данных. Что может привести к не консистенции данных о которой мы даже не узнаем. А идея предполагала что в что в базах данных получателя будет только один источник записи - это очередь. А с учётом миграции получается два.