📌 7 вопросов с подвохом по Архитектуре: хореография микросервисов + понимание брокеров в EDA 📌


1️⃣ Когда хореография микросервисов хуже оркестрации?

✔️ Сложные линейные бизнес-процессы с кучей условий (сложный онбординг, платежные цепочки, обращения тех поддержки и др)

✔️ Надо явно видеть шаги процесса и управлять им

✔️ Когда важны SLA и время на выполнение шагов

В таких случаях удобнее, когда:
+ есть компонент, который явно хранит состояние процесса
+ видно “шаги” и переходы по ним
С этим помогает оркестрация.



2️⃣ Сервис записал данные в свою БД, но упал до публикации события. Что произойдёт в хореографии и как это чинить?

Многие говорят «ретраи к брокеру» (повторные запросы) и всё. Но это лишь часть ответа.

Ситуация:
Обработка данных на микросервисе прошла, но событие в брокер не опубликовано → остальные сервисы никогда не узнают об изменении.

Решение:
Transactional Outbox / Outbox pattern:
В одной транзакции к БД с бизнес-данными пишем запись в специальную outbox-таблицу.

Отдельный воркер (фоновый процесс) читает из outbox и публикует событие в брокер, с ретраями.

Также иногда используют Change Data Capture (CDC) по БД - отслеживание изменений.



3️⃣ Как в хореографии реализовать шаг, который зависит сразу от двух событий из разных сервисов?

Например: бонус начисляем только если есть "пользователь зарегистрирован" и "оплачен первый заказ"?

Нужен агрегатор/process manager (отдельный сервис/Kafka Streams и др), который:
+ хранит состояние двух параметров: userId - , orderId
+ пришло первое событие — пометили “жду второе”
+ пришло второе — выполняем действие (начисляем бонус)

Это уже кусочек оркестрации, спрятанный внутри одного сервиса.

Также нужно учесть что делать, если второе событие не пришло.



4️⃣ Как в хореографии реализовать таймаут шага?
Например, оплата должна пройти за 15 минут, иначе заказ отменяем.

Используется process manager / timeout-сервис / scheduler:

1. При старте процесса публикуется событие "оплата началась"

2. Параллельно где-то создаётся “таймер” на 15 минут (например, Cron)

3. Если за 15 минут не пришло событие "Платеж успешен" / "Ошибка оплаты":
+ таймер генерирует событие "Ошибка таймаута по платежу",
+ другие сервисы реагируют: отменяют заказ, снимают резерв и т.п.

Важно понять: управление интервалами времени в работе процесса не решается «само по себе» брокером — нужен компонент, который хранит состояние ожидания.


5️⃣ Биллинг слушает событие "Заказ оплачен" и должен списать деньги ровно один раз. Любое сообщение может прийти дважды. Как вы гарантируете отсутствие двойного списания?

Ошибочный ответ:
«брокер гарантирует доставку ровно один раз»

Реализуем проверки на уровне потребителя события:
+ идемпотентность операций: бизнес-ключ (orderId + paymentId)
+ уникальность в БД на этот ключ
+ таблица processed_messages с messageId и состоянием.


6️⃣ Можно ли построить систему только на хореографии, без оркестрации?

В теории — можно, но:
+ всё равно появятся сервисы-агрегаторы / процесс-менеджеры / scheduler’ы, которые управляют процессами
+ как только один сервис начинает хранить состояние процесса и ждать другие события, он выполняет роль локального оркестратора.

Более правильный ответ: в реальных системах почти всегда смесь подходов хореографии и оркестрации.


7️⃣ Вы добавляете новый микросервис в существующую хореографию процессов. Как сделать так, чтобы он не поломал остальных, когда начнёт слушать существующие события?

Новый сервис должен быть пассивным наблюдателем:
+ слушает существующие события без изменения процесса их работы
+ никакие его действия не должны влиять на текущие цепочки по процессам

Важно:
+ не добавлять обязательные поля в существующие события (сообщения), которые отправляем в брокер
+ не менять JSON (формат сообщений) уже используемых событий
+ если нужно другое поведение — вводить новые типы событий, а не менять старые.


Какие ещё вопросы по брокерам и хореографии вы встречали на собеседованиях на СА? Делитесь в комментариях ✍️


#АрхитектураGA