Optimizando la generación de contenido en Brenia: de procesos secuenciales a ejecución paralela
En el proyecto Brenia, nuestra plataforma de generación de contenido asistido por IA, nos enfrentamos a un cuello de botella crítico: los tiempos de espera en la generación de imágenes mediante APIs externas impactaban significativamente la experiencia de usuario. Tras un análisis detallado de los logs de producción, identificamos que el proceso secuencial era el principal responsable de una latencia superior a los 160 segundos en casos complejos.
Desafíos en la arquitectura actual
El flujo original dependía de una ejecución lineal donde cada paso debía completarse antes de iniciar el siguiente. Cualquier fallo en la generación de una imagen implicaba reintentar el flujo completo, desperdiciando recursos valiosos como la generación de texto de apoyo o copys que ya estaban listos.
Estrategias de optimización
Para mitigar esto, implementamos tres cambios fundamentales:
- Fail-fast y reintentos aislados: Introdujimos una lógica de reintento granular dentro del servicio de generación. Ahora, si una llamada a la API de imágenes falla, el sistema intenta recuperarse localmente en lugar de reiniciar todo el job.
- Ejecución asíncrona: Movimos la generación de sugerencias inteligentes fuera de la ruta crítica, permitiendo que el editor de contenido esté disponible tan pronto como los elementos principales (imagen y copy) estén listos.
- Procesamiento en batch: Adoptamos el uso de colas de Laravel con
Bus::batch. Al generar carruseles, los slides ahora se procesan de forma concurrente en lugar de uno tras otro.
// Ejemplo ilustrativo de procesamiento en lotes
use Illuminate\Support\Facades\Bus;
$batch = Bus::batch([
new GenerateSlideJob($slideData1),
new GenerateSlideJob($slideData2),
new GenerateSlideJob($slideData3),
])->then(function ($batch) {
// Finalizar ensamble tras éxito total
})->dispatch();
Gracias a estos ajustes, hemos logrado reducir el tiempo de generación para carruseles complejos de 155 segundos a aproximadamente 35 segundos, mejorando radicalmente la capacidad de respuesta de nuestra infraestructura sin necesidad de escalar los recursos del servidor de manera prematura.
