Понимаете ли вы принципы работы событийно управляемой архитектуры

Что проверяют

Понимаете ли вы, что даёт обмен событиями и чем за это платят. На Java-собеседовании разговор быстро уходит в детали: гарантия доставки, порядок, дубли, как это выглядит в Spring и в брокере. Общих слов про слабую связанность не хватит.

Как отвечать

Начните с разделения понятий. Событие это факт о прошлом («заказ оплачен»), команда это просьба о будущем. Издатель не знает потребителей, они подписываются сами. Связанность падает, наблюдаемость усложняется.

Разберите уровни:

• внутри приложения: публикация через ApplicationEventPublisher, слушатель с @EventListener, а для согласованности с транзакцией @TransactionalEventListener с фазой после коммита;
• между сервисами: брокер. Kafka это лог с порядком внутри партиции и чтением с произвольного смещения, RabbitMQ очередь с маршрутизацией и подтверждениями;
• стили: уведомление о факте, событие с данными внутри, восстановление состояния проигрыванием журнала.

Скажите про честные проблемы и про то, чем их закрывают. Доставка «хотя бы один раз» означает дубли, поэтому потребитель делается идемпотентным: ключ сообщения и таблица уже обработанных. Запись в базу и отправка в брокер не складываются в одну транзакцию, отсюда паттерн исходящих сообщений. Порядок гарантирован только внутри партиции, значит ключ партиционирования выбирается по сущности. На неразобранные сообщения заводят отдельную очередь.

Где спотыкаются

Говорят, что события ускоряют систему. Асинхронность не делает работу быстрее, она снимает ожидание с вызывающего и добавляет задержку до результата. Выигрыш в устойчивости и независимости выката, а не в производительности.

Второе: обещают доставку ровно один раз как настройку. Транзакции в Kafka дают такую семантику для цепочки чтение, обработка, запись внутри самой Kafka. Как только появляется внешняя база или вызов чужого сервиса, гарантию снова даёт идемпотентность потребителя.

Третье: забывают про схему и отладку. Событие живёт дольше кода, который его породил, поэтому нужны версионирование формата, совместимость в обе стороны и сквозной идентификатор запроса, иначе разбор инцидента превращается в чтение логов пяти сервисов подряд.