Давай подведем промежуточный итог по сильным сторонам событийной архитектуры.
1. Слабая связанность
Жёсткая связанность бэкенд-сервисов (когда сервис А вызывает сервис Б по HTTP) приводит к цепным реакциям. Если сервис доставки упал, сервис заказов зависнет в ожидании ответа.
Как это решает событийная архитектура: Брокер служит буфером, который разрывает прямую связь. Сервис заказов просто кидает событие в брокер и за 10 миллисекунд отвечает клиенту «ОК».
Если сервис доставки упал, события просто будут копиться в брокере. Когда сервис поднимется, он спокойно их вычитает. Никто никого не блокирует.
2. Масштабируемость
Каждый элемент системы может масштабироваться независимо. Если сервис генерации PDF-отчетов не справляется с нагрузкой, мы можем запустить 50 экземпляров этого консьюмера, и они будут параллельно разгребать очередь. При этом код продюсера вообще не изменится.
Масштаб BigTech: Брокеры спроектированы для колоссальных нагрузок. Например, LinkedIn (создатели Kafka) еще в 2019 году обрабатывали более 7 триллионов сообщений в день, используя свыше 7 миллионов партиций. Сейчас эти цифры кратно больше.
3. Расширяемость
Событийная архитектура легко расширяется под новые продуктовые требования.
- Однажды созданное событие (например,
UserRegistered - Завтра бизнесу понадобится новый сервис — «Аналитика новых пользователей». Тебе не нужно идти в команду регистрации и просить их дописать код для вызова твоего сервиса. Ты просто подключаешь нового консьюмера к брокеру и начинаешь читать уже существующие события.