Reducir una API de e-commerce de 10s a menos de 1s

El trabajo de rendimiento empieza con humildad. Cuando un endpoint tarda alrededor de 10 segundos, el primer impulso suele ser reescribir la función más visible. Rara vez es el mejor primer paso.

La ruta correcta es medir, aislar y cambiar la parte más pequeña del sistema que explica la mayor parte de la latencia.

Empieza con una traza

Antes de tocar código, captura el ciclo de vida de la petición con una herramienta APM o de profiling. El objetivo es responder preguntas básicas:

• ¿El tiempo se va en Python, SQL, llamadas de red, renderizado o serialización?
• ¿El endpoint repite la misma consulta demasiadas veces?
• ¿Hay cálculos costosos por registro en vez de por lote?
• ¿La petición depende de servicios externos?
• ¿El camino lento es común o depende de datos concretos?

Sin esta evidencia, optimizar se convierte en adivinar.

Busca multiplicación

Muchas APIs de negocio lentas no lo son por una línea dramática. Lo son porque una operación razonable se repite demasiadas veces. Puede aparecer como consultas N+1, comprobaciones repetidas de permisos, cálculos repetidos de precio, disponibilidad de producto ineficiente o serialización innecesaria de grafos grandes de objetos.

En sistemas ERP y e-commerce, la multiplicación se esconde dentro de reglas de negocio. Precios, impuestos, rutas de stock, condiciones por cliente y visibilidad de catálogo pueden parecer simples por separado y volverse caros bajo carga.

Corrige la forma del trabajo

Cuando el cuello de botella está claro, la mejor optimización suele ser estructural:

• Leer datos en lote en vez de consultar por registro.
• Llevar filtros y agregaciones a PostgreSQL cuando tenga sentido.
• Cachear resultados intermedios estables durante la petición.
• Eliminar cálculos duplicados.
• Evitar cargar campos que la respuesta no usa.
• Separar responsabilidades síncronas y asíncronas.

El objetivo no es código ingenioso. El objetivo es hacer menos trabajo.

Valida con entradas reales

Después del cambio, prueba con datos parecidos a producción. Una mejora que funciona con 20 productos puede no funcionar con 20.000. Una consulta aceptable para un cliente puede ser lenta para clientes con tarifas complejas, muchas direcciones o reglas fiscales especiales.

Las mejoras de rendimiento deberían validarse con:

• Tiempos antes y después.
• Número de consultas.
• Slow query logs o planes de consulta.
• Casos de negocio representativos.
• Monitorización tras el despliegue.

Déjalo mantenible

El último paso es dejar el sistema más fácil de entender. Añade comentarios solo cuando la razón de negocio no sea evidente. Añade tests sobre el camino optimizado. Registra la suposición de rendimiento importante, por ejemplo evitar consultas por línea o mantener un cálculo en lote.

Reducir un endpoint de 10 segundos a menos de 1 segundo no es magia. Es diagnóstico disciplinado, simplificación cuidadosa y respeto por las reglas de negocio que hicieron complejo el endpoint.