Sua API começa a retornar timeouts sob carga, mas a CPU do banco está baixa e as queries parecem rápidas. Onde você procura?

Essa combinação aponta para esgotamento do pool de conexões ou um limite de concorrência parecido, não para o banco estar lento. Olhe o tempo de espera no pool e as conexões ativas versus ociosas: as requisições estão na fila por uma conexão enquanto cada uma que a segura demora demais, muitas vezes por causa de uma chamada externa lenta dentro de uma transação, um timeout faltando ou uma conexão vazada que nunca volta. Corrija primeiro o tempo de retenção, depois dimensione o pool de forma deliberada.

Queries rápidas mais requisições lentas significa que o tempo está sendo gasto esperando por algo, e o pool é o suspeito de sempre. Eu olharia o tempo de espera no pool e quanto tempo as conexões ficam retidas, mais a contagem do lado do banco de sessões ativas versus ociosas em transação. Um monte de idle in transaction é o sinal claro: alguém abriu uma transação e depois fez um trabalho que não é de banco. Isso é quase sempre a causa, uma chamada HTTP para um provedor de pagamento ou uma serialização lenta dentro de uma transação, então cada requisição segura uma conexão por um segundo em vez de cinco milissegundos e o pool esvazia com uma fração do tráfego. A correção é encurtar a seção crítica: fazer a chamada externa antes ou depois da transação, adicionar timeouts de statement e de transação, e garantir que todo caminho devolva a conexão mesmo em caso de erro. Só depois disso eu mexeria no tamanho, e com cuidado, porque cada instância multiplica aquilo. Aumentar o pool sem corrigir o tempo de retenção só move a fila para o banco e transforma um endpoint lento numa queda geral.