Optimización del rendimiento

Una API Spring Boot casi siempre es rápida en desarrollo. La base de datos contiene treinta filas, se ejecuta en la misma máquina y un solo usuario llama a un endpoint a la vez. En estas condiciones nada puede ir lento, y precisamente por eso los problemas de rendimiento nunca se descubren antes de producción.

El desfase se debe a tres diferencias que el entorno de desarrollo no reproduce. El volumen: una unión sin índice cuesta lo mismo con treinta filas y se convierte en un barrido completo con tres millones. La latencia de red: una consulta SQL pasa de 0,1 ms en local a 2 ms contra un servidor remoto, y una operación que dispara doscientas pasa de veinte milisegundos a cuatro segundos. Y la concurrencia: lo que funciona bien para un usuario puede agotar un pool de conexiones con cincuenta.

Ante una API lenta, la tentación es añadir caché. Casi siempre es prematuro: la caché oculta el síntoma, complica la invalidación, introduce incoherencias y no corrige nada. Antes de optimizar, se mide; antes de poner en caché, se corrige la causa. En una API Spring típica, tres de cada cuatro veces esa causa es el número de consultas SQL ejecutadas, no su duración individual.