Queues & workers : BullMQ, Sidekiq, quelle solution pour ton SaaS ?

Introduction

Tu envoies des emails en masse ? Gères des exports lourds ? Publies sur les réseaux ou traites des vidéos ?
Si tu fais tout ça en live côté API… tu vas vite cramer ton infra.
La solution : externaliser ces traitements via une jobs queue, et les exécuter en asynchrone avec un worker.
Dans cet article, on te guide pas à pas : choisir entre BullMQ, Sidekiq, et co., mettre en place une architecture robuste, et monitorer tes jobs comme un pro.

Pourquoi utiliser une queue pour ton SaaS ?

Un SaaS, c’est asynchrone par nature

• 🔄 Un export CSV de 20 000 lignes ne doit pas bloquer ton frontend

• 📬 Un email transactionnel ne doit pas planter si l'API de SendGrid est lente

• 📹 Un traitement vidéo ou IA ne peut pas tourner sur ta route API

Tout ça doit passer par une jobs queue, exécutée par un worker dédié.

Les avantages clés

• Fiabilité : les jobs sont relancés en cas d’échec

• Scalabilité : tu peux paralléliser et gérer la charge

• Responsivité : ton API reste rapide, même sous forte demande

Les 2 grands acteurs : BullMQ vs Sidekiq

BullMQ 🟥 (Node.js + Redis)

• Développé par les créateurs de Bull (NestJS, Node.js)

• Moderne, typé TypeScript

• Repose sur Redis

• Interface admin avec Arena ou Bull Board

Sidekiq 🔴 (Ruby + Redis)

• Standard de facto dans l’écosystème Ruby on Rails

• Maturité +++

• Dashboard intégré, retries automatiques

• Versions Pro / Entreprise disponibles

Tableau comparatif

| Critère           | BullMQ                        | Sidekiq                       |
|-------------------|-------------------------------|-------------------------------|
| Langage           | Node.js / TypeScript          | Ruby                          |
| Backend           | Redis                         | Redis                         |
| Monitoring        | BullBoard, Arena              | Interface native              |
| Retrys & Delays   | Oui                           | Oui                           |
| Priorités         | Oui                           | Oui                           |
| Cron intégré      | Via `@bull-board/express` ou `bullmq-pro` | Oui (native)               |
| Ecosystème SaaS   | NestJS, Next.js, Express      | Rails, Hanami, Sinatra        |

Architecture type avec BullMQ dans un SaaS

1. Redis pour le stockage temporaire des jobs

→ Chaque job est une tâche sérialisée avec ses données (payload)

2. Une queue nommée (ex : emailQueue, exportQueue)

→ Tu peux en créer plusieurs selon les types de jobs

3. Un ou plusieurs workers

→ Des process indépendants qui consomment la queue et exécutent les tâches

// queue.ts
import { Queue } from 'bullmq';

export const emailQueue = new Queue('emailQueue', {
  connection: { host: 'localhost', port: 6379 },
});

// add job
await emailQueue.add('sendWelcomeEmail', { userId: 'abc123' });

// worker.ts
import { Worker } from 'bullmq';

new Worker('emailQueue', async (job) => {
  const { userId } = job.data;
  await sendEmail(userId);
});

Monitoring et alerting des jobs

🎛️ UI

• BullMQ : utilise bull-board ou arena pour visualiser les jobs (pending, failed, completed)

• Sidekiq : dashboard intégré avec retries, temps d'exécution, mémoire

🔔 Alerte en cas d’échec

• Slack webhook (via BullMQ events)

• Logs vers Logtail / Datadog

• Notifications via Sentry ou Airbrake

Bonnes pratiques pour une jobs queue SaaS

À faire ✅

• Séparer les queues par domaine métier (email, background, billing…)

• Gérer les échecs avec retries et dead letter queue

• Surveiller le taux d’échec et les délais

• Nettoyer régulièrement les jobs terminés

À éviter ❌

• Mettre trop de logique dans le job lui-même (préférer des fonctions isolées)

• Lancer trop de workers sur une petite infra

• Empiler les jobs sans mécanisme de throttle

Cas d’usage SaaS : quel outil pour quel job ?

Outils alternatifs à considérer

Conclusion

BullMQ ou Sidekiq, ce n’est pas une bataille, c’est une question d’écosystème.
Si ton SaaS tourne sur Node.js (Next, Nest, Express), BullMQ est ton meilleur allié.
Si tu es sur Rails, Sidekiq est déjà dans ton ADN.
Mais dans tous les cas, pense observabilité, scalabilité, et fiabilité dès le départ.
➡️ Besoin d’un guide complet pour structurer ton backend SaaS ? Télécharge notre blueprint archi sur saas-path.com.