Кейс: Feign-клиент без таймаута положил пул потоков сервиса

Сервис ходил во внутренний API через Feign-клиент с настройками по умолчанию. Через несколько месяцев в проде downstream начал изредка отвечать медленно — не падал, просто держал соединение открытым дольше обычного.

Там, где connectTimeout и readTimeout не заданы явно через feign.client.config, таймаут может оказаться на порядок больше, чем терпит SLA сервиса, — или зависеть от дефолтов конкретного Client под капотом. Запросы к медленному downstream копились: каждый занимал поток из пула Tomcat на неопределённое время.

Пул исчерпался — новые входящие запросы к самому сервису встали в очередь и начали получать таймаут уже от своих клиентов. Внешне выглядело так, будто упал сам сервис, хотя он был жив и просто ждал ответа от чужого API.

Что спросят следом: почему один медленный downstream должен ронять весь сервис, а не только запросы, которые его касаются. Правильный ответ — bulkhead: выделенный пул потоков или коннектов под конкретную зависимость, чтобы её деградация не съедала ресурсы для остальных эндпоинтов.

Таймаут на HTTP-клиенте — не деталь конфигурации, а условие, без которого один медленный сосед останавливает весь сервис.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки