Cómo aceleramos nuestra API de Laravel cinco veces

Por dónde empezar la optimización

La optimización siempre debe empezar por las mediciones, no por las suposiciones. Antes de cambiar el código, perfilamos solicitudes reales y descubrimos que el 80% del tiempo de respuesta se dedicaba al acceso a la base de datos, no a la lógica de negocio. Por eso el primer objetivo fue precisamente el trabajo con los datos.

Luchando contra el problema N+1

La causa más frecuente de los endpoints lentos resultó ser el problema N+1: para una lista de cien entidades se ejecutaban más de cien consultas adicionales a las relaciones. La carga ansiosa mediante with() lo redujo a unas pocas consultas.

Qué cambiamos exactamente

• Añadimos carga ansiosa para todas las relaciones usadas en los recursos de respuesta.
• Activamos la protección contra la carga perezosa en el entorno de desarrollo para detectar el N+1 en etapas tempranas.
• Trasladamos los agregados pesados a consultas optimizadas separadas.

Almacenamos en caché los datos calientes

Trasladamos los catálogos que cambian con poca frecuencia y las consultas pesadas a Redis con una invalidación bien pensada basada en eventos. Esto eliminó una parte significativa de la carga de PostgreSQL y estabilizó la latencia bajo el tráfico pico.

Modo residente

El paso final fue ejecutar la aplicación en modo residente, lo que eliminó la sobrecarga de la inicialización en frío del framework en cada solicitud. En conjunto, todas las medidas dieron una aceleración de cinco veces del tiempo medio de respuesta.

Conclusiones

Un enfoque sistemático —medir, encontrar el cuello de botella, corregirlo y volver a medir— permitió lograr una aceleración múltiple sin reescribir la aplicación. La lección principal: optimiza según los datos del perfilado, no según la intuición.