Какая у вас интеграция: односторонняя или двусторонняя и кто инициирует запросы

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

Насколько хорошо вы знаете систему за пределами своего сервиса. Интервьюеру важно, различаете ли вы направление потока данных и сторону, которая начинает обмен: от этого зависят таймауты, повторы и идемпотентность. Следом спрашивают: «Что будет, если смежная система недоступна?»

Как отвечать

Опишите конкретную интеграцию по трём осям:

• направление данных: только отдаём (выгрузка, события), только забираем или обмениваемся в обе стороны, например заказ уходит в систему доставки, а статусы возвращаются;
• инициатор: кто открывает соединение. Мы вызываем их REST через RestClient или Feign, они шлют нам вебхук, или обе стороны пишут в Kafka и читают из неё;
• синхронность: ждёт ли вызывающий ответа. Синхронный HTTP связывает доступность систем, очередь их развязывает, но добавляет задержку и вопрос порядка сообщений.

Двусторонний обмен данными не требует двух инициаторов. Если вы раз в минуту опрашиваете их API за статусами, инициатор всегда вы, а данные текут в обе стороны.

Дальше покажите, как это отражалось в коде. Когда инициатор вы, нужны таймауты на соединение и чтение, повторы с экспоненциальной задержкой и circuit breaker (Resilience4j). Когда инициируют вас, нужны идемпотентная обработка по ключу запроса, проверка подписи или mTLS и быстрый ответ с обработкой в фоне. Для надёжной отправки событий вместе с записью в базу назовите паттерн transactional outbox.

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

Путают одностороннюю интеграцию с fire-and-forget. «Отправляем и не ждём ответа» говорит о синхронности, а не о направлении.

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

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