Connection Pool Exhausted: O Erro Que Derruba APIs Spring Boot em Produção

Se você trabalha com APIs Java em produção, existe um erro que aparece cedo ou tarde:

HikariPool-1 - Connection is not available, request timed out

Ou então:

Connection pool exhausted

E honestamente?

Esse é um dos erros mais perigosos em aplicações Spring Boot.

Porque normalmente ele aparece:

• em produção

• sob carga

• em horário crítico

• quando sistema começa crescer

E quando acontece: a API praticamente entra em colapso.

Usuários começam a enfrentar:

• lentidão

• timeout

• travamentos

• erro 500

• filas gigantes

• requisições presas

E muita gente resolve isso da pior forma possível:

“Aumenta o pool.”

Só que na maioria dos casos: isso NÃO resolve o problema real.

Neste guia vamos entender:

• o que é connection pool

• por que o erro acontece

• causas reais

• gargalos ocultos

• configuração correta do HikariCP

• tuning

• monitoramento

• boas práticas enterprise

Tudo de forma prática.

O Que é Connection Pool?

Toda vez que sua aplicação acessa o banco: ela precisa abrir conexão.

Só que abrir conexão é caro.

Muito caro.

Se cada request abrisse conexão do zero: a performance seria desastrosa.

Então aplicações modernas usam: Connection Pool.

Como Funciona?

O pool mantém conexões já abertas.

Fluxo:

Request chega

↓

Pool entrega conexão pronta

↓

Query executa

↓

Conexão volta para o pool

Muito mais rápido.

O Spring Boot Usa HikariCP

Por padrão o Spring Boot utiliza: HikariCP

E honestamente? ele é excelente.

Extremamente performático.

O Problema Real

O erro acontece quando:

Todas as conexões estão ocupadas

e novas requisições precisam esperar.

Quando o limite é atingido: o pool esgota.

Resultado: timeout.

Exemplo do Erro

HikariPool-1 - Connection is not available, request timed out after 30000ms

Tradução: a aplicação tentou pegar conexão durante 30 segundos… e não conseguiu.

O Que Isso Significa?

Significa que: alguma coisa está segurando conexões por tempo demais.

E aqui começa a investigação real.

O Maior Erro dos Desenvolvedores

Achar que: “faltam conexões”.

Na prática: muitas vezes o problema é:

• query lenta

• transação longa

• lock

• N+1 query

• deadlock

• vazamento de conexão

Aumentar o Pool Pode PIORAR Tudo

Esse é um erro clássico.

Imagine:

Banco suporta: 100 conexões.

Você aumenta pool para: 200.

Resultado:

• banco colapsa

• CPU explode

• memória explode

• lock aumenta

E o sistema piora ainda mais.

Causa Mais Comum: Query Lenta

Exemplo clássico:

SELECT *
FROM orders
WHERE status = 'PENDING'

Sem índice.

Tabela: 5 milhões de registros.

Resultado: query demora segundos.

Conexão fica presa.

Pool começa acabar.

Outra Causa Muito Comum: N+1 Query

Exemplo:

orders.forEach(order -> {
    order.getItems().size();
});

Isso pode gerar: centenas de queries.

Resultado:

• lentidão

• consumo de conexão

• gargalo absurdo

Problema de Transação Longa

Outro vilão.

@Transactional
public void process() {

    externalApi.call();

    repository.save(entity);
}

Enquanto API externa responde: a conexão pode ficar ocupada.

Isso é MUITO perigoso.

Forma Correta

Evitar operações lentas dentro da transação.

Vazamento de Conexão

Outro problema grave.

Exemplo clássico sem fechamento:

Connection conn = datasource.getConnection();

Sem:

• close()

• try-with-resources

Conexão nunca volta para pool.

Configuração Padrão do HikariCP

spring:
  datasource:
    hikari:
      maximum-pool-size: 10

Muita gente acha: 10 é pouco.

Nem sempre.

Quantidade Ideal de Conexões

Depende:

• CPU

• banco

• queries

• concorrência

• arquitetura

Mais conexões ≠ mais performance.

Configuração Recomendada

spring:
  datasource:
    hikari:
      minimum-idle: 5
      maximum-pool-size: 20
      idle-timeout: 30000
      max-lifetime: 1800000
      connection-timeout: 30000

Mas tuning depende do cenário.

Como Descobrir o Problema Real

A pergunta correta NÃO é: “quantas conexões existem?”

A pergunta correta é: “quem está segurando conexões?”

Ferramentas Importantes

PostgreSQL

SELECT * FROM pg_stat_activity;

Excelente para identificar:

• queries lentas

• locks

• conexões presas

MySQL

SHOW PROCESSLIST;

Monitoramento do HikariCP

Ative métricas.

Com:

• Micrometer

• Prometheus

• Grafana

Você consegue visualizar:

• conexões ativas

• idle

• waiting

• timeout

Erro Muito Comum em APIs

Misturar:

• processamento pesado

• banco

• API externa

• loops gigantes

Tudo na mesma request.

Resultado: conexão fica presa tempo demais.

Solução Moderna

Desacoplar processamento pesado.

Usar:

• Kafka

• RabbitMQ

• filas

• processamento assíncrono

Outro Problema Perigoso: Open Session in View

Muitos projetos usam:

spring.jpa.open-in-view=true

Isso mantém sessão aberta até fim da request.

Pode aumentar:

• tempo de conexão

• risco de gargalo

Muita arquitetura moderna desativa isso.

Connection Pool Não Faz Milagre

Outro ponto importante.

Se:

• query é ruim

• banco está lento

• índice não existe

O pool não resolve.

Como Melhorar Performance Realmente

Índices corretos

Maior impacto normalmente.

Queries otimizadas

Fundamental.

Reduzir transações longas

Muito importante.

Cache

Ajuda absurdamente.

Paginação

Evita consultas gigantes.

Processamento assíncrono

Excelente para escala.

Benchmark Real

APIs pequenas

Pool 10~20 normalmente resolve.

SaaS médios

20~50 dependendo carga.

Sistemas enterprise

Necessário:

• observabilidade

• tuning

• análise contínua

Sintomas de Pool Exhausted

Sintoma	Frequência
API lenta	Muito alta
Timeout	Muito alta
CPU alta banco	Alta
Requests presas	Alta
Erro 500	Alta
Lentidão aleatória	Muito alta

Connection Pool vs Banco

Outro ponto importante:

o gargalo pode estar:

• no banco

• não na aplicação

Exemplo:

• lock

• deadlock

• disco lento

• falta índice

• vacuum atrasado

PostgreSQL Sofre Muito Com Isso

Principalmente quando:

• existe lock

• query ruim

• excesso de conexões

Como Arquiteturas Modernas Resolvem Isso

Grandes sistemas normalmente usam:

• cache

• CQRS

• mensageria

• processamento assíncrono

• read replicas

• observabilidade

Porque banco relacional não escala infinitamente.

O Erro Mais Perigoso

Ignorar o problema.

Porque no começo: só fica lento.

Depois: o sistema inteiro para.

Vale a Pena Aprender Isso?

Muito.

Porque esse é exatamente o tipo de problema que: separa:

• backend básico

• backend enterprise

Nossa Conclusão

O erro: Connection Pool Exhausted

raramente significa: “faltam conexões”.

Na maioria das vezes ele revela:

• query ruim

• arquitetura ruim

• transação longa

• falta de observabilidade

• gargalo escondido

Entender connection pool corretamente é obrigatório para qualquer backend moderno com:

• Spring Boot

• PostgreSQL

• MySQL

• APIs escaláveis

• microsserviços

Principalmente em produção.