Когда-то я собесился в команду, которая переходила с монолита на микросервисы, и мне задали такой вопрос: Кейс: У нас есть событие «Пользователь зарегистрировался». В системе есть несколько микросервисов: Пользователи, Заказы, Нотификации.

Когда пользователь регистрируется, каждый сервис должен сделать что-то свое: • сервис заказов – создать пустую корзину • сервис нотификаций – отправить приветственное письмо • возможно, появятся другие подписчики в будущем

Вопрос: Как спроектировать взаимодействие между сервисами, чтобы они были максимально независимыми? Какой интеграционный шаблон лучше использовать?

На самом деле это не хитрый вопрос. Если спокойно подумать, ответ довольно прямолинейный: для такого сценария идеально подходит паттерн Публикация / Подписка (Pub/Sub).

Как это работает: Сервис Пользователи публикует событие UserRegistered в брокер сообщений (Kafka/RabbitMQ). А дальше  начинается то, за что микросервисы вообще любят:

• Сервис Заказы подписывается на событие и выполняет свою логику • Сервис Нотификации подписывается на то же событие и делает свое • Завтра появится сервис аналитики и он просто подпишется на событие

Издатель не знает и не должен знать, кто именно потребляет событие и что с ним делают. Он просто сообщает факт:  «пользователь зарегистрирован».

А что с другими вариантами? Прямые вызовы API (Point-to-Point):

Сервис Пользователи после регистрации сам синхронно вызывает API Заказов, потом Нотификаций, потом еще что-то. Если сервис Заказов ляжет – регистрация не пройдет. Отсюда создается жесткая связь и цепочка зависимостей 😑

Общая база данных (Shared Database):

Все сервисы лезут в одну БД, чтобы смотреть в таблицу users и отслеживать новых пользователей. Теряется независимость данных – главный принцип микросервисов. Любое изменение схемы таблицы users тянет за собой деплой всех сервисов, а сама БД становится единой точкой отказа.

Единый оркестратор (API Gateway):

Gateway принимает запрос на регистрацию, вызывает Пользователей, а потом сам дергает все остальные сервисы. И если он упадет, то вся цепочка будет парализована.

Лайфхак для собеса:

Если тебя спрашивают про интеграцию микросервисов, задавай встречные вопросы, чтобы точно понять контекст:: • Критично ли, чтобы все подписчики обработали событие сразу? • Допустимы ли дубли событий? • Нужно ли сохранять порядок событий?

✅ Что же ответить на собесе? Я бы использовал шаблон Публикация/Подписка (Pub/Sub) через брокер сообщений (Kafka/RabbitMQ).

Сервис Пользователи публикует событие UserRegistered, а сервисы Заказы, Нотификации и любые будущие потребители подписываются на него независимо.

Это снижает связность, упрощает масштабирование и позволяет добавлять новую бизнес-логику без переписывания уже существующих сервисов 👆

Главное не растеряться и спокойно рассуждать вслух. Назвал Pub/Sub, объяснил про низкую связность, упомянул масштабирование и этого уже достаточно для мидла.

Сеньор добавил бы, что можно учесть в ТЗ и какие риски могут быть на проде. Вот, собственно, и вся разница.