Кейс: пул HikariCP опустел за минуту без единой ошибки конфигурации

Сервис держал пул на 20 соединений, формула pool_size = Tn × (Cm − 1) + 1 была посчитана верно под обычную нагрузку. Ночью downstream-сервис начал отвечать за 8-10 секунд вместо привычных 50ms — сеть деградировала, а не упала совсем.

Каждый запрос держал соединение с БД открытым всё время ожидания ответа от downstream, потому что вызов происходил внутри той же транзакции: метод делал SQL-запрос, потом HTTP-вызов, потом коммит. Пока соединение не освобождалось, оно недоступно другим потокам.

За минуту все 20 соединений оказались забронированы медленными запросами. Новые запросы не падали сразу — они вставали в очередь HikariCP и ждали connectionTimeout, по умолчанию 30 секунд, прежде чем получить SQLTransientConnectionException.

@Transactional public void process(Order order) { repository.save(order); notifyDownstream(order); // HTTP-вызов внутри транзакции // держит connection всё это время }

Правильный фикс — не увеличить пул, а вынести HTTP-вызов за пределы транзакции: закоммитить SQL-часть отдельно, вызвать downstream после. Увеличение пула лечит симптом на день, пока трафик снова не подрастёт.

Транзакция должна держать соединение ровно на время работы с БД, а не на время ожидания сети.

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

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

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