Какой был опыт интеграции с внешними сервисами и какие проблемы возникали

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

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

Как отвечать

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

• HTTP-клиент: в Spring для нового кода RestClient или интерфейсы с @HttpExchange, в реактивном стеке WebClient, без Spring java.net.http.HttpClient. RestTemplate в режиме поддержки;
• таймауты: соединения и чтения задаются явно. У многих клиентов по умолчанию ожидание не ограничено, и один зависший партнёр съедает весь пул потоков;
• устойчивость: Resilience4j с Retry и экспоненциальной задержкой, CircuitBreaker, Bulkhead. Повторять можно только идемпотентные операции, для платежей нужен ключ идемпотентности;
• лимиты: ответ 429 и заголовок Retry-After, свой лимитер на исходящие запросы;
• асинхронность: вебхуки приходят повторно и не по порядку, их обрабатывают по идентификатору события. Надёжную отправку своих событий даёт transactional outbox;
• тесты: WireMock вместо живого сервиса, Testcontainers, контрактные тесты через Pact или Spring Cloud Contract;
• наблюдаемость: correlation id в логах, маскирование персональных данных, метрики времени ответа и доли ошибок по каждому партнёру.

Если серьёзных интеграций не было, расскажите о самой сложной из тех, что были, и честно разделите, что знаете из практики, а что из документации.

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

Рассказывают, что всё прошло гладко. Без проблемы история пустая, а интеграций без проблем не бывает.

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

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