Как событийно-ориентированная архитектура решает проблемы современных веб-приложений

[powerman]

То, что Вы тут описываете как Решение (именно так, с большой буквы РРы :)) "современных" проблем, на самом деле описано Фаулером в статье Event Sourcing 15 лет назад. И за эти годы накопилось достаточно опыта, чтобы понять, что для абсолютного большинства проектов это решение создаёт намного больше проблем, чем решает. Для бизнеса Event Sourcing это дорого, сложно и обычно не нужно. См. например Почему Event Sourcing — это антипаттерн для взаимодействия микросервисов. Без событий современные проекты действительно редко обходятся, но вот использование их в стиле Event Sourcing — должно быть очень хорошо продуманным решением, и уж точно не первым вариантом используемым по умолчанию на большинстве проектов.

[Vadem]

Event Sourcing и EDA — это разные вещи. EDA появилась задолго до Event Sourcing. Но в статье вроде и не утверждается, что EDA это что-то новое. Там говорится лишь, что EDA решат современные проблемы.

Кстати статья про антипаттерн именно про то, что не стоит смешивать события, которые вы используете для хранения состяния(ES), с событиями, которые вы используете для взаимодействия компонет системы(EDA).

[dedmagic]

Брокер сообщений выглядит как узкое место системы. Если генераторов и потребителей событий может быть сколько угодно и их можно масштабировать, то общаются они все через одного брокера. Мало того, брокер может и упасть, что приведёт к полной остановке системы.
Или есть варианты с пулом брокеров?

[shuron]

Да и на это есть ответ. Класс distributed broker с их самым известным представителем apache kafka

[mrxanru]

Мне кажется кафка достаточно масштабируемая и отказоустойчивая для таких случаев.