Quels sont les avantages et limites de BullMQ, et quand l’utiliser ?

Question

IT Interview Practice · Accepted Answer

BullMQ est une file de jobs Node.js fondée sur Redis. Évaluez-la pour **un travail pouvant finir après la réponse HTTP et nécessitant suivi ou reprises**.

Un gros rapport produit dans la requête peut faire attendre jusqu’au timeout. Une file accepte le travail, retourne un ID et traite séparément.

## 1. Comprendre le changement apporté

```text
[User] -> [API: submit job] -> [Redis / BullMQ] -> [Worker]
                |                                   |
          [Return job ID]                       [Saved report]
```

Le producteur soumet, le worker exécute. L’utilisateur suit la progression et télécharge le rapport enregistré une fois prêt.

Le calcul prend toujours du temps. Mais sa durée ne dépend plus d’une requête ouverte et les workers sont gérés séparément des serveurs API.

## 2. Relier avantages et besoins

| Besoin | Capacité BullMQ | Choix restant à l’application |
| --- | --- | --- |
| Revenir d’erreurs temporaires | Reprises avec backoff | Quelles erreurs répéter et quand arrêter. |
| Exécuter plus tard ou régulièrement | Jobs différés et planification | Timing exigé et comportement après panne. |
| Maîtriser la charge | Concurrence et limites de débit | Bornes sûres des bases et services. |
| Augmenter la capacité de fond | Workers supplémentaires | Capacité de la dépendance suivante. |

Pour le rapport, ces fonctions évitent un moteur maison d’états et de reprises. Elles permettent suivi et diagnostic. Ajouter des workers aide seulement sans surcharger les dépendances.

## 3. Comprendre le problème de correction principal

Le worker peut sauvegarder le rapport puis tomber avant de déclarer la fin. Une reprise peut refaire le travail. C’est plus grave pour débiter de l’argent ou envoyer un message.

Utilisez une identité métier stable. La répéter doit réutiliser ou remplacer sûrement le résultat, sans effet supplémentaire : c’est l’idempotence. Pour les effets externes, utilisez l’aide du fournisseur et rapprochez les issues incertaines. [Jobs idempotents](https://docs.bullmq.io/patterns/idempotent-jobs).

Si enregistrer une donnée doit aussi créer un job, traitez l’intervalle entre les écritures. Une outbox garde l’instruction dans la transaction métier ; un publisher la livre ensuite. La livraison peut se répéter, donc le worker reste idempotent.

## 4. Inclure l’exploitation de Redis et des workers

Redis contient du travail en attente : persistance, mémoire et reprise comptent. Configurez noeviction ; supprimer silencieusement des clés est inadapté aux jobs à conserver. Testez la restauration sans supposer qu’un redémarrage applicatif sûr couvre toute panne Redis. [Conseils de production](https://docs.bullmq.io/guide/going-to-production).

Placez les gros fichiers dans un stockage adapté et passez des références. Définissez la conservation des jobs terminés ou échoués pour maîtriser Redis.

Un calcul CPU lourd peut bloquer l’event loop et empêcher le renouvellement du verrou. Le job peut être déclaré stalled puis rejoué. Utilisez des worker threads ou processeurs isolés appropriés et surveillez ces cas. [Stalled jobs](https://docs.bullmq.io/guide/jobs/stalled).

## 5. Donner une recommandation conditionnelle

- Choisissez BullMQ pour du fond observable, des reprises et des workers indépendants si l’équipe sait exploiter Redis fiablement.
- Gardez simple une action locale triviale sans suivi durable ni exécution séparée.
- Évaluez un journal durable d’événements si le besoin principal est un replay historique par plusieurs consommateurs plutôt que finir des tâches.

Testez dépendance en panne, crash après sauvegarde et reprise après interruption. Vérifiez un statut fiable et aucun résultat contradictoire lors des répétitions.

**À retenir :** BullMQ coordonne les jobs. L’application garantit la correction métier et l’équipe exploite la file.

Besoin	Capacité BullMQ	Choix restant à l’application
Revenir d’erreurs temporaires	Reprises avec backoff	Quelles erreurs répéter et quand arrêter.
Exécuter plus tard ou régulièrement	Jobs différés et planification	Timing exigé et comportement après panne.
Maîtriser la charge	Concurrence et limites de débit	Bornes sûres des bases et services.
Augmenter la capacité de fond	Workers supplémentaires	Capacité de la dépendance suivante.

1. Comprendre le changement apporté

2. Relier avantages et besoins

3. Comprendre le problème de correction principal

4. Inclure l’exploitation de Redis et des workers

5. Donner une recommandation conditionnelle

Questions connexes