Um job em lote noturno está esgotando as conexões do banco e a API está dando timeout. Como você corrige?

Interrompa o dano imediato limitando ou pausando o job em lote, e então separe as cargas para elas não competirem. Aponte o job em lote para uma réplica de leitura se ele for pesado em leitura, dê a ele um pool de conexões próprio com teto rígido, e divida o trabalho em pedaços com pausas para ele nunca monopolizar o banco. No longo prazo, reserve capacidade para o tráfego interativo e alerte sobre saturação do pool de conexões antes de os usuários notarem.

Primeiro, estanque a hemorragia. Pause ou limite o job em lote, porque o caminho interativo é o que o cliente sente e o lote pode rodar uma hora depois sem ninguém se importar. A correção tentadora é aumentar o máximo de conexões, e isso normalmente piora, já que cada conexão tem custo de memória e de escalonamento e você acaba com um banco se debatendo em vez de um banco meramente ocupado. Então a correção real é isolamento. Se o job é pesado em leitura, ele vai para uma réplica de leitura, o que tira a carga do primário por completo. Ele ganha credenciais próprias e um pool próprio com teto rígido, dimensionado para que, mesmo totalmente saturado, sobre bastante folga para a API. E o job em si é dividido em pedaços, processando em lotes com uma pausa curta e um timeout de statement, em vez de uma transação enorme que segura locks e estoura o atraso de replicação. Depois a prevenção: alerte sobre utilização do pool e consultas de longa duração em um limiar que dispare antes de virar visível ao usuário, para a gente saber pelo monitoramento e não por tickets de suporte.