Un job por lotes nocturno está agotando las conexiones de base de datos y la API está dando timeout. ¿Cómo lo arreglas?

Corta el daño inmediato limitando o pausando el job por lotes, y luego separa las cargas para que no puedan competir. Apunta el job a una réplica de lectura si es intensivo en lecturas, dale su propio pool de conexiones con un techo duro, y trocea el trabajo con pausas para que nunca monopolice la base de datos. A más largo plazo, reserva capacidad para el tráfico interactivo y alerta sobre la saturación del pool antes de que los usuarios lo noten.

Primero, parar la hemorragia. Pausa o limita el job por lotes, porque el camino interactivo es lo que sienten los clientes y el lote puede correr una hora después sin que a nadie le importe. El arreglo tentador es subir el máximo de conexiones, y eso normalmente lo empeora, ya que cada conexión tiene coste de memoria y de planificación y acabas con una base de datos dando tumbos en vez de una que solo está ocupada. Así que el arreglo real es el aislamiento. Si el job es intensivo en lecturas se mueve a una réplica de lectura, lo que quita la carga del primario por completo. Recibe sus propias credenciales y su propio pool con un techo duro, dimensionado para que incluso saturado del todo deje mucho margen a la API. Y el job en sí se trocea, así procesa por lotes con una pausa corta y un timeout de sentencia, en vez de una transacción enorme que retiene bloqueos y dispara el retraso de replicación. Luego la prevención: alertar sobre el uso del pool y las consultas largas en un umbral que salte antes de que sea visible para el usuario, así nos enteramos por la monitorización y no por los tickets de soporte.