El 12 de septiembre de 2026 marcó un punto de inflexión en la infraestructura de PrensaBot. Lo que comenzó como una sospecha –feeds que no se actualizaban a tiempo– se convirtió en la exposición de una peligrosa ilusión: asumir que porque un cron está configurado en cPanel, el trabajo se está ejecutando correctamente. El equipo descubrió, con horas de retraso, que procesos se congelaban en silencio o que múltiples ejecuciones competían entre sí, bloqueando operaciones críticas.
La anatomía del problema: cuando los procesos se devoran
El escenario era complejo. En un entorno de hosting compartido donde no se podía ejecutar un demonio persistente como Supervisor, los trabajos programados (crons) eran la columna vertebral. Sin embargo, la falta de protección generaba condiciones de carrera. Un proceso anterior podía quedar congelado, consumiendo indefinidamente un lock de base de datos, mientras que dos ejecuciones simultáneas de un mismo comando competían por los mismos recursos, colapsando tablas de jobs y deteniendo el flujo de redacción automatizada.
La solución no podía depender únicamente de logs de error de Apache o LiteSpeed, inaccesibles o crípticos para un operador no técnico. La misión era clara: construir un sistema donde fuera imposible fallar en silencio. Si algo se trababa, debía "gritar" de inmediato.
La arquitectura de la confiabilidad: locks, heartbeats y workers disciplinados
Tras probar diferentes enfoques, el equipo implementó una estrategia multicapa que transformó la operación:
-
Worker disciplinado: Se configuró el comando
queue:work --stop-when-empty --max-jobs=20 --max-time=180. Esta instrucción permite que un worker procese jobs de la cola de Laravel de manera controlada y luego finalice, ideal para entornos sin demonios persistentes. -
Lockfile a nivel de sistema: Se creó un archivo de bloqueo en
/tmp/pb_worker.lock. Este mecanismo a nivel de sistema operativo previene ejecuciones solapadas del mismo proceso, garantizando que solo una instancia corra a la vez. -
Panel de System Operations: Se desarrolló una pantalla dentro del panel administrativo de PrensaBot (construido con Filament) que muestra en tiempo real el último latido (*heartbeat*), el estado de las colas y las alertas del sistema. Es un electrocardiograma de la infraestructura.
El aprendizaje clave: visibilidad sobre fe
El principal cambio de paradigma fue entender que la confiabilidad de un sistema no reside en que nunca falle –eso es una utopía–, sino en que sea imposible que falle en silencio. La observabilidad pasó de ser un lujo a una necesidad fundamental. Hoy, cualquier desviación en el ritmo de procesamiento o un lock retenido más de lo esperado se manifiesta de inmediato en el panel de control, permitiendo una intervención rápida antes de que impacte en la producción de contenidos.
Esta arquitectura, documentada en los ADR 008 y 009 internos, sienta las bases para un sistema más resiliente. Demuestra que incluso en entornos con restricciones, como un hosting compartido, es posible implementar mecanismos robustos de control y monitoreo, reemplazando la fe ciega en los scripts por datos concretos y ojos siempre abiertos sobre la redacción.
Deja una respuesta