Tu API empieza a devolver timeouts bajo carga, pero la CPU de la base de datos está baja y las consultas parecen rápidas. ¿Dónde miras?

Esa combinación apunta a agotamiento del pool de conexiones o a un límite de concurrencia parecido, no a que la base de datos esté lenta. Mira el tiempo de espera del pool y las conexiones activas frente a las ociosas: las peticiones hacen cola por una conexión mientras cada poseedor la retiene demasiado, a menudo por una llamada externa lenta dentro de una transacción, un timeout que falta o una conexión filtrada que nunca se devuelve. Arregla primero el tiempo de retención y luego dimensiona el pool a conciencia.

Consultas rápidas más peticiones lentas significa que el tiempo se va esperando algo, y el pool es el sospechoso habitual. Miraría el tiempo de espera del pool y cuánto se retienen las conexiones, más el recuento del lado de la base de datos de sesiones activas frente a idle in transaction. Un montón de idle in transaction es la pista: algo abrió una transacción y luego hizo trabajo que no es de base de datos. Esa es casi siempre la causa, una llamada HTTP a una pasarela de pago o un paso de serialización lento metido dentro de una transacción, así que cada petición retiene una conexión un segundo en vez de cinco milisegundos y el pool se vacía con una fracción del tráfico. El arreglo es acortar la sección crítica: hacer la llamada externa antes o después de la transacción, añadir timeouts de sentencia y de transacción, y asegurar que todos los caminos devuelven su conexión incluso ante un error. Solo después tocaría el tamaño, y con cuidado, porque cada instancia lo multiplica. Subir el pool sin arreglar el tiempo de retención solo mueve la cola a la base de datos y convierte un endpoint lento en una caída global.