Propuesta Técnica: Optimización de Procesamiento de Reportes Usando Servidores de Segundo Plano

Problema

La generación de reportes pesados en la infraestructura actual provoca sobrecarga en los servidores principales que atienden la API.
Aunque contamos con dos servidores de segundo plano que actualmente procesan colas y jobs programados vía Redis, estos no están optimizados para aprovechar su capacidad en reportes que requieren mayores límites de tiempo y memoria.

Alternativas de Solución

Alternativa 1: Exponer la API en servidores de segundo plano con dominio personalizado

Ejemplo: reports.idbi.pe apuntando a los servidores de segundo plano, donde los reportes se procesan en primer plano.

Pros:

Reutiliza infraestructura ya existente.
Procesamiento más potente dedicado a reportes sin afectar servidores principales.
Entrega inmediata en solicitudes especiales de reporte.

Contras:

Tiempo de respuesta largo y bloqueo de la conexión HTTP.
Menor tolerancia a errores en ejecución prolongada.
Requiere reconfiguración para optimizar uso.

Diagrama de flujo:

flowchart TB
    A[Usuario] --> B[Dominio reports.idbi.pe]
    B --> C[Servidor Segundo Plano - Procesamiento en 1er Plano]
    C --> D[Generar Reporte]
    D --> E[Enviar Resultado Directo al Usuario]

Alternativa 2: Sistema de reportes completamente en segundo plano

La API principal recibe la solicitud, la encola, y los servidores segundo plano procesan y devuelven resultado posteriormente.

Pros:

No bloquea conexión HTTP del usuario.
Escalable y seguro.
Mejor aprovechamiento de infraestructura.

Contras:

No entrega inmediata.
Necesidad de endpoints adicionales para estado y descarga.

Diagrama de flujo:

flowchart TB
    A[Usuario] --> B[API Principal]
    B --> C[Cola Redis: reports]
    C --> D[Servidor Segundo Plano - Worker Laravel]
    D --> E[Generar Reporte]
    E --> F[Storage Compartido/S3]
    F --> G[Notificación al Usuario / Consulta de Estado]
    G --> H[Descarga de Reporte]

Alternativa 3: Aumentar tiempos de ejecución en servidores principales

Configurar servidores API para soportar reportes pesados en primer plano.

Pros:

Implementación rápida.
Entrega inmediata sin arquitectura adicional.

Contras:

Riesgo de bloqueos en servidores principales.
No aprovecha infraestructura segundo plano.
Escalabilidad reducida.

Diagrama de flujo:

flowchart TB
    A[Usuario] --> B[API Principal]
    B --> C[Procesar Reporte en 1er Plano]
    C --> D[Generar Reporte]
    D --> E[Enviar Resultado Directo al Usuario]

Recomendación

Se recomienda la Alternativa 2: Sistema de reportes completamente en segundo plano por:

Mantener disponibilidad del frontal.
Aprovechar plenamente servidores de segundo plano.
Mayor escalabilidad y menor riesgo operativo.

Próximos pasos sugeridos:

Configurar cola reports en Redis para ser procesada solo por servidores segundo plano.
Implementar Jobs especializados con mayores límites de tiempo y memoria.
Crear endpoints para solicitar reportes, consultar estado y descargar resultados.
Ajustar supervisores (supervisord o systemd) en segundo plano para soportar carga proyectada.
Pruebas de carga y validación antes de despliegue en producción.