Pourquoi quitter Redis pour migrer vers SolidQueue

• Rails 8 supprime la dépendance à Redis de sa stack par défaut et bascule tous les traitements vers une base de données relationnelle (RDB) via SolidQueue·SolidCache·SolidCable
• Redis est rapide et fiable, mais entraîne une complexité opérationnelle liée à la configuration, la sécurité, la gestion de cluster et les sauvegardes
• SolidQueue s’appuie sur la fonctionnalité PostgreSQL FOR UPDATE SKIP LOCKED pour mettre en œuvre un traitement parallèle sans contention
• Des fonctionnalités payantes de Redis+Sidekiq comme les tâches récurrentes, le contrôle de concurrence et le tableau de bord de monitoring (Mission Control) sont fournies gratuitement
• Pour la plupart des applications Rails, SolidQueue suffit, et Redis ne reste nécessaire que dans certains cas demandant un traitement temps réel ultra-rapide

---

Le coût caché de Redis

• Au-delà du simple coût d’hébergement, Redis impose une charge continue de gestion : installation, maintenance, configuration de sécurité, gestion de cluster HA
  • Il faut mettre en place la connexion réseau et les règles de pare-feu entre Rails et Redis, l’authentification client et l’orchestration des processus Sidekiq
• En cas d’incident, il faut déboguer simultanément Redis et le SGBDR, avec en plus une stratégie de sauvegarde double
• À l’inverse, une stack Rails sans Redis permet de se contenter de gérer uniquement PostgreSQL, ce qui simplifie l’exploitation

Fonctionnement de SolidQueue

• SolidQueue utilise la fonctionnalité PostgreSQL FOR UPDATE SKIP LOCKED afin que plusieurs workers récupèrent des tâches en parallèle sans conflit de verrouillage (lock contention)
• Structure principale des tables
  1. solid_queue_jobs : stockage des métadonnées des tâches
  2. solid_queue_scheduled_executions : attente des tâches planifiées
  3. solid_queue_ready_executions : file des tâches prêtes à être exécutées
• Les processus worker, dispatcher, scheduler et supervisor coopèrent en interrogeant périodiquement différentes tables
• Grâce à la conception MVCC de PostgreSQL et à autovacuum, même de gros volumes d’insertions et de suppressions sont traités de manière stable

Planification des tâches récurrentes

• SolidQueue fournit nativement des tâches récurrentes de style cron, configurées dans le fichier config/recurring.yml
• Le scheduler place en file les tâches arrivées à échéance, puis programme automatiquement leur prochaine exécution
• Il s’appuie sur la bibliothèque Fugit pour analyser des plannings en langage naturel, et sur Concurrent::ScheduledTask pour créer des threads
• Il reprend l’approche de planification déterministe de GoodJob, afin de préserver le planning même après redémarrage du processus

Contrôle de concurrence

• SolidQueue utilise le pattern de sémaphore POSIX pour prendre en charge la limitation des exécutions simultanées par tâche
  • Exemple : avec limits_concurrency to: 1, key: ->(user) { user.id }, une seule tâche par utilisateur peut s’exécuter à la fois
• La définition d’une expiration du sémaphore (duration) permet d’éviter les conflits et les deadlocks
• Tables associées
  • solid_queue_semaphores : suivi des limites de concurrence
  • solid_queue_blocked_executions : stockage des tâches en attente

Monitoring avec Mission Control

• Mission Control Jobs est un tableau de bord open source gratuit pour Rails 8, qui peut être monté simplement sur la route /jobs
• Fonctionnalités principales
  • état des files en temps réel, suivi des tâches en échec, contrôle des retries et de l’abandon
  • visualisation de la chronologie des tâches planifiées et récurrentes
  • graphiques de débit et de métriques par file
• Les requêtes basées sur SQL permettent une analyse directe dans la base de données sans outil supplémentaire

Migration de Sidekiq vers SolidQueue

• Étape 1 : définir config.active_job.queue_adapter = :solid_queue
• Étape 2 : exécuter bundle add solid_queue, puis rails solid_queue:install et db:migrate
• Étape 3 : convertir les plannings cron de sidekiq.yml vers recurring.yml
• Étape 4 : ajouter jobs: bundle exec rake solid_queue:start au Procfile
• Étape 5 : supprimer les gems liées à Redis et Sidekiq
• Le code ActiveJob existant continue de fonctionner sans modification

Cas où Redis reste nécessaire

• traitement soutenu de plusieurs milliers de tâches par seconde
• systèmes temps réel où une latence inférieure à 1 ms est indispensable
• besoin d’une architecture pub/sub complexe ou d’opérations avancées de rate limiting et de compteurs
• Par exemple, Shopify exploite une infrastructure Redis avec 833 requêtes par seconde et 1 172 processus workers

Guide d’implémentation concret

• Lors de la création d’une nouvelle application Rails 8, SolidQueue, SolidCache et SolidCable sont configurés automatiquement
• Il est recommandé de définir dans config/database.yml une connexion de base de données distincte pour la queue
• Ajouter l’authentification de Mission Control et monter la route /jobs
• Ajouter jobs: bundle exec rake solid_queue:start dans Procfile.dev, puis lancer l’ensemble avec bin/dev
• Après création de tâches de test, leur état peut être vérifié dans Mission Control

Problèmes fréquents et solutions

• Une configuration sur base de données unique est possible, mais réduit la flexibilité en production
• En production, il faut impérativement ajouter une authentification à Mission Control
• Les intervalles de polling par défaut sont de 1 seconde pour les tâches planifiées et de 0,2 seconde pour les tâches immédiates, ce qui convient à la plupart des applications
• En cas d’utilisation de ActionCable/Turbo Streams, il faut configurer SolidCable avec une connexion DB distincte

Scalabilité et performances

• SolidQueue est suffisamment scalable pour la plupart des applications Rails
• Avec PostgreSQL, il peut traiter 200 à 300 tâches par seconde, et 37signals traite 20 millions de tâches par jour sans Redis
• Tableau comparatif

  Élément	Redis + Sidekiq	SolidQueue
  Complexité de configuration	Service séparé nécessaire	Utilise la DB intégrée
  Langage de requête	Commandes Redis	SQL
  Monitoring	Tableau de bord séparé	Mission Control
  Scénarios de panne	6 ou plus	2
  Débit	Plusieurs milliers/s	200–300/s
  Cas adaptés	99,9 % des apps	95 % des apps

Conclusion

• Redis et Sidekiq sont d’excellentes technologies, mais elles entraînent une complexité et un coût excessifs pour la plupart des applications Rails
• SolidQueue permet, avec une base de données unique, de simplifier l’exploitation, réduire les coûts et améliorer la maintenance
• À l’ère de Rails 8, il est recommandé d’adopter SolidQueue comme choix par défaut