Были ли интеграции с другими системами

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

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

Как отвечать

Назовите конкретную интеграцию: платёжный шлюз, 1С, CRM, банк, служба доставки. Опишите протокол (REST, gRPC, SOAP, обмен через Kafka, вебхуки) и дальше то, что вы сделали в Go для надёжности:

• таймауты: у http.DefaultClient таймаута нет, поэтому свой http.Client с Timeout и context.WithTimeout на каждый вызов;
• ретраи: с экспоненциальной задержкой и джиттером и только для идемпотентных операций. Для платежей нужен ключ идемпотентности, иначе повтор спишет деньги дважды;
• защита от каскада: circuit breaker (например, sony/gobreaker) и ограничение частоты через golang.org/x/time/rate, если у партнёра лимит запросов;
• вебхуки: проверка подписи HMAC, быстрый ответ 200 и обработка из очереди, дедупликация по идентификатору события;
• согласованность: transactional outbox, чтобы событие не потерялось, если база запись приняла, а отправка упала;
• тесты и наблюдаемость: httptest.NewServer для имитации партнёра, логи с идентификатором запроса, метрики времени ответа и ошибок по каждой интеграции.

Результат формулируйте своими словами и цифрами, которые вы действительно видели: сколько интеграций, сколько инцидентов было до и после. Если интеграций не было, честно скажите и опишите, как спроектировали бы одну по этому же списку.

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

Забывают defer resp.Body.Close() и не дочитывают тело. Соединения не возвращаются в пул, и под нагрузкой кончаются сокеты.

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

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