Как сократить время ответа от внешнего партнера при синхронной и асинхронной интеграции

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

Понимаете ли вы, что скорость партнёра вы не контролируете, а контролируете только то, сколько ваш сервис его ждёт и как часто к нему ходит. Следом обычно спрашивают, что станет с вашим сервисом, если партнёр начнёт отвечать по 30 секунд.

Как отвечать

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

Для синхронной схемы:

• таймауты: отдельно на соединение и на чтение. У HttpURLConnection и java.net.http.HttpClient по умолчанию ждать можно бесконечно, поэтому таймауты задаются явно;
• кэш: справочники и повторяющиеся запросы кладите в Caffeine или Redis с TTL, согласованным с тем, как часто данные меняются у партнёра;
• пул соединений и keep-alive: переиспользование соединения экономит TCP и TLS handshake на каждом вызове;
• параллельные вызовы: независимые запросы через CompletableFuture.allOf или виртуальные потоки Java 21 занимают время самого медленного, а не сумму;
• circuit breaker из Resilience4j: после серии ошибок перестаёт ходить к партнёру и сразу отдаёт фолбэк.

Для асинхронной:

• очередь: запрос уходит в Kafka или RabbitMQ, клиент получает 202 Accepted с идентификатором, результат приходит вебхуком, событием или через опрос статуса;
• ретраи: с экспоненциальной задержкой и dead letter queue для сообщений, которые так и не прошли;
• идемпотентность: ключ запроса, чтобы повторная доставка не создала второй платёж.

Оговоритесь честно: асинхронность не ускоряет партнёра, она убирает его задержку из пользовательского запроса. Мерить стоит p95 и p99 через Micrometer, а не среднее.

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

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

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

Называют асинхронную интеграцию «быстрее» и забывают про её цену: статусы, повторную доставку, дубли сообщений и то, что клиенту теперь нужно как-то узнать результат.