Tuve un trabajo en segundo plano en Kubernetes que parecía super simple: cada cinco minutos comprobar trabajos pendientes y procesarlos. El código original usaba un temporizador dentro de la propia aplicación con setInterval y se desplegó en tres pods para alta disponibilidad. Gran error.
El lunes por la mañana los usuarios recibieron correos duplicados y la CPU de la base de datos se disparó. Al revisar los logs aparecía siempre lo mismo: Pod A procesando el mismo trabajo, Pod B procesando el mismo trabajo, Pod C haciendo exactamente lo mismo. Los tres pods despertaban a la vez, consultaban la base de datos, encontraban los mismos trabajos pendientes y los procesaban en paralelo. Clásica condición de carrera.
Probé múltiples soluciones complejas y frágiles: locks en la base de datos, locks en Redis, elección de líder. Funcionaban a medias y aumentaban la complejidad operacional. Entonces me di cuenta de algo obvio: por qué coordinar tres workers cuando sólo necesito que uno ejecute cada trabajo.
La solución simple fue convertir el temporizador interno en un endpoint HTTP. En lugar de ejecutar setInterval en cada pod, añadí una ruta POST que lanza la comprobación de trabajos pendientes y devuelve un resultado. Después usé un scheduler externo para invocar ese endpoint cada cinco minutos. Por ejemplo con GCP Cloud Scheduler o con servicios equivalentes en AWS o Azure el esquema es el mismo: el scheduler hace una petición HTTP y el balanceador de carga entrega esa petición a uno solo de los pods, con lo que el trabajo se ejecuta una única vez.
Ventajas de esta aproximación respecto a los locks: no hay condiciones de carrera porque sólo llega una petición por ejecución, mucho menos código porque desaparece la lógica de coordinación, mayor fiabilidad al apoyarse en un scheduler gestionado, depuración más sencilla gracias a logs de peticiones claros, y portabilidad entre plataformas usando cron, EventBridge, Cloud Scheduler, o cualquier scheduler externo. En muchas arquitecturas la mejor solución distribuida es no distribuir ese trabajo en concreto.
Patrón práctico: deja de preguntarte como coordinar múltiples instancias y empieza a preguntarte si necesitas varias instancias haciendo esa tarea. Muchos trabajos en segundo plano encajan perfecto con triggers externos: procesamiento de ficheros mediante eventos de almacenamiento, calentamiento de caches mediante hooks de despliegue, tareas de limpieza programadas, o comprobaciones de salud con monitorización externa.
En Q2BSTUDIO aplicamos este tipo de decisiones prácticas y resilientes cuando desarrollamos aplicaciones a medida y software a medida. Como empresa de desarrollo de software especializada en aplicaciones a medida, inteligencia artificial, ciberseguridad y servicios cloud, ofrecemos soluciones que simplifican la operación y reducen alertas nocturnas.
Si tu arquitectura necesita integrar schedulers gestionados o migrar timers internos a triggers externos podemos ayudarte a diseñar e implementar la mejor estrategia con enfoque en fiabilidad y mantenimiento. Consulta nuestros servicios en servicios cloud AWS y Azure o descubre cómo automatizar tareas recurrentes con automatización de procesos. También trabajamos soluciones avanzadas de inteligencia artificial, ia para empresas y agentes IA, así como inteligencia de negocio y power bi para mejorar la observabilidad y reducción de costes operativos.
Resultados personales: meses después de aplicar este patrón cero duplicados, cero alertas a las 2 AM y mucho menos tiempo dedicado a depurar condiciones de carrera. A veces la solución más efectiva en sistemas distribuidos es no distribuir el trabajo.
Si tienes una experiencia parecida o una historia sobre tareas en segundo plano en Kubernetes comparte abajo, en Q2BSTUDIO nos encanta aprender de casos reales y proponer mejoras prácticas para infraestructuras modernas.