¿Cómo coordinar un cron entre varios nodos NestJS?

Question

IT Interview Practice · Accepted Answer

Define primero qué significa «solo un nodo ejecuta el cronjob». **Evitar ejecuciones simultáneas y evitar efectos de negocio repetidos son requisitos diferentes.** Un planificador compartido coordina; la operación debe ser segura tras caídas y reintentos.

Considera facturación diaria desplegada en tres nodos NestJS. Queremos ejecutar el trabajo sin generar otra factura al reiniciar un worker.

## 1. Entiende por qué todos empiezan

Cada instancia registra su propio callback cron. A la hora indicada, cada una puede iniciar independientemente:

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

Un indicador isRunning solo existe en un proceso. waitForCompletion de NestJS evita solapamientos locales, no coordina otros nodos. Tres indicadores iguales siguen siendo tres decisiones. [Planificación NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Necesitamos un lugar compartido que determine el trabajo existente y quién puede ejecutarlo.

## 2. Elige la coordinación

| Situación | Opción que evaluar | Responsabilidad restante |
| --- | --- | --- |
| La plataforma ya ofrece trabajos programados | Planificar fuera de las instancias web | Solapamiento, recuperación y ejecuciones perdidas. |
| El equipo ya opera BullMQ | Job Scheduler compartido y cola dedicada | Concurrencia global y reintentos seguros. |
| La tarea debe permanecer en nodos de aplicación | Bloqueo o lease compartido | Propiedad, expiración y workers antiguos. |

Si Redis y BullMQ ya existen, un planificador compartido con ID estable es práctico. Separa planificación y workers para que añadir nodos web no cree horarios independientes.

En una versión compatible, limita a uno la concurrencia global de la cola dedicada. Eso restringe jobs activos entre workers; concurrencia local uno permite que varios workers ejecuten jobs distintos. [Concurrencia global](https://docs.bullmq.io/guide/queues/global-concurrency).

Decide qué hacer si ayer sigue ejecutándose: esperar, omitir o combinar ocurrencias. Define zona horaria y recuperación de fechas de negocio perdidas tras una caída.

## 3. Protege la factura, no solo el job

Un worker puede crear una factura y caer antes de registrar finalización. La recuperación puede repetir el job aunque la factura exista.

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

Usa una clave estable, como cliente y periodo de facturación. Una restricción única y una transacción pueden unir factura y registro de ejecución completada. El reintento encuentra el resultado previo en vez de crear otra factura.

Para proveedores externos, utiliza su clave de idempotencia si existe y concilia resultados inciertos. Un ID de job o registro retenido no garantiza permanentemente que una acción no se repita. [Jobs idempotentes](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Conoce los límites del bloqueo

Adquiere el bloqueo compartido atómicamente. Usa token de propiedad, expiración y renovación; libera solo si coincide el token. Si no, un worker antiguo podría liberar el bloqueo de otro nuevo.

Al expirar, un worker pausado puede reanudarse mientras otro ya trabaja. Las escrituras críticas pueden requerir fencing tokens: números crecientes que el destino verifica para rechazar propietarios antiguos. Un timeout largo no elimina el riesgo.

Sin coordinación disponible, decide si esperar en lugar de ejecutar sin propiedad. Suele ser más seguro para acciones importantes.

## 5. Verifica fallos

Prueba varios nodos, caída tras crear factura, pausa mayor que el lease, desconexión de Redis y despliegue gradual. Registra fecha, worker, intento y resultado para distinguir intentos repetidos de efectos repetidos.

**Recuerda:** coordinar horario → limitar ejecución compartida → acción segura al reintentar → probar recuperación. «Un job activo» no demuestra exactamente un efecto de negocio.

Situación	Opción que evaluar	Responsabilidad restante
La plataforma ya ofrece trabajos programados	Planificar fuera de las instancias web	Solapamiento, recuperación y ejecuciones perdidas.
El equipo ya opera BullMQ	Job Scheduler compartido y cola dedicada	Concurrencia global y reintentos seguros.
La tarea debe permanecer en nodos de aplicación	Bloqueo o lease compartido	Propiedad, expiración y workers antiguos.

1. Entiende por qué todos empiezan

2. Elige la coordinación

3. Protege la factura, no solo el job

4. Conoce los límites del bloqueo

5. Verifica fallos

Preguntas relacionadas