Comment coordonner un cron entre plusieurs nœuds NestJS ?

Question

IT Interview Practice · Accepted Answer

Précisez d’abord « un seul nœud exécute le cronjob ». **Empêcher des exécutions simultanées et empêcher un effet métier répété sont deux besoins distincts.** Le planificateur coordonne ; l’opération doit rester sûre après crash et reprise.

Prenons la facturation quotidienne sur trois nœuds NestJS. Le travail doit se faire sans nouvelle facture à chaque redémarrage du worker.

## 1. Comprendre le démarrage de tous les nœuds

Chaque instance enregistre son callback cron. À l’heure prévue, chacune peut démarrer :

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

Un indicateur isRunning n’existe que dans un processus. waitForCompletion de NestJS évite les chevauchements locaux, pas ceux des autres nœuds. Trois indicateurs restent trois décisions. [Planification NestJS](https://docs.nestjs.com/techniques/task-scheduling).

Il faut un point partagé décidant du travail et de son propriétaire.

## 2. Choisir la coordination

| Situation | Option à évaluer | Responsabilité restante |
| --- | --- | --- |
| La plateforme fournit déjà des jobs planifiés | Planifier hors des instances web | Chevauchements, reprise et horaires manqués. |
| L’équipe exploite BullMQ | Job Scheduler partagé et file dédiée | Concurrence globale et répétitions sûres. |
| La tâche doit rester dans l’application | Verrou ou bail partagé | Propriété, expiration et workers périmés. |

Si Redis et BullMQ existent, un planificateur partagé à ID stable est pratique. Séparez horaire et workers pour que de nouveaux nœuds web ne créent pas d’horaires indépendants.

Sur une version compatible, fixez la concurrence globale de la file à un. Cela limite les jobs entre workers ; une concurrence locale de un autorise toujours plusieurs workers sur des jobs différents. [Concurrence globale](https://docs.bullmq.io/guide/queues/global-concurrency).

Décidez quoi faire si hier tourne encore : attendre, sauter ou regrouper. Définissez fuseau et rattrapage des dates métier manquées.

## 3. Protéger la facture, pas seulement le job

Un worker crée la facture puis tombe avant de marquer la fin. La récupération peut répéter le job malgré la facture existante.

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

Utilisez une clé métier stable, comme client et période. Contrainte unique et transaction peuvent relier facture et marqueur de fin. La reprise retrouve alors le résultat existant.

Avec un fournisseur externe, utilisez sa clé d’idempotence et rapprochez les résultats incertains. Un ID de job ou une trace conservée ne garantit pas indéfiniment l’absence de répétition métier. [Jobs idempotents](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Connaître les limites du verrou

Acquérez le verrou atomiquement. Utilisez jeton propriétaire, expiration et renouvellement ; libérez seulement avec le même jeton. Sinon un ancien worker peut libérer le verrou du nouveau.

Après expiration, un worker suspendu peut reprendre alors qu’un autre travaille. Les écritures critiques peuvent exiger des fencing tokens : numéros croissants que la destination contrôle pour rejeter les anciens propriétaires. Un long timeout n’élimine pas ce risque.

Sans coordination, décidez d’attendre plutôt que d’exécuter sans propriété. C’est souvent plus sûr pour des opérations importantes.

## 5. Vérifier les pannes

Testez plusieurs nœuds, crash après facture, pause dépassant le bail, perte de Redis et déploiement progressif. Enregistrez date, worker, tentative et résultat pour distinguer répétition d’essai et d’effet.

**À retenir :** horaire partagé → exécution limitée → action métier répétable sûrement → reprise testée. « Un job actif » ne prouve pas exactement un effet métier.

Situation	Option à évaluer	Responsabilité restante
La plateforme fournit déjà des jobs planifiés	Planifier hors des instances web	Chevauchements, reprise et horaires manqués.
L’équipe exploite BullMQ	Job Scheduler partagé et file dédiée	Concurrence globale et répétitions sûres.
La tâche doit rester dans l’application	Verrou ou bail partagé	Propriété, expiration et workers périmés.

1. Comprendre le démarrage de tous les nœuds

2. Choisir la coordination

3. Protéger la facture, pas seulement le job

4. Connaître les limites du verrou

5. Vérifier les pannes

Questions connexes