Une mécanique de livraison & retry (back-off) qui relance vos emails à votre place
Mécanique de livraison & retry (backoff) une fonctionnalité du module Email & cache de Clustraly. La mécanique de livraison & retry orchestre l'envoi asynchrone des emails, réclame chaque message atomiquement et réessaie en back-off exponentiel jusqu'à cinq tentatives.
Vos emails ne dépendent plus d'un envoi réussi du premier coup. La file les met de côté, un worker les envoie, et chaque échec déclenche une nouvelle tentative espacée sans jamais dédoubler un message.
Une livraison qui insiste à votre place
Vous enfilez le message, le pipeline s'occupe du reste. La requête web se contente de mettre l'email en file ; un worker l'envoie ensuite, réessaie en cas d'échec et n'abandonne qu'après cinq tentatives. Vous obtenez une livraison qui ne repose plus sur un envoi parfait du premier coup.
- Envoi découplé de la requête web
- Réessais automatiques jusqu'à 5 tentatives
- File persistée pour historique et traçabilité
Jamais deux fois le même email
Chaque message passe de « pending » à « sending » par une réclamation atomique. Même si deux ticks cron tournent en même temps, un seul peut s'emparer d'une ligne impossible d'envoyer le même email en double. Vos destinataires reçoivent un message, pas trois.
- Transition pending → sending verrouillée
- Ticks cron concurrents sans collision
- Aucun doublon côté destinataire
Un back-off qui laisse respirer le serveur distant
Un échec ne renvoie pas l'email en boucle serrée. Les tentatives s'espacent selon une grille [1 min, 5 min, 30 min, 2 h, 6 h], jusqu'à cinq essais. Un incident passager se résout tout seul au prochain créneau, sans marteler un serveur qui refuse temporairement.
- Grille d'attente 1 min → 6 h
- Plafond fixe à 5 tentatives
- Moins de pression sur les serveurs distants
Rien ne reste coincé en « sending »
Un worker interrompu peut laisser un message figé en cours d'envoi. La routine reap() repère ces lignes bloquées ou orphelines et les remet dans le circuit. Un envoi qui a calé ne disparaît pas en silence : il repart.
- Détection des envois figés en « sending »
- Reprise des lignes orphelines
- Aucun message abandonné sur un worker interrompu
Vous gardez l'interrupteur de la file
L'IA propose la mécanique, vous gardez la main. Un interrupteur email.queue_enabled active ou coupe la mise en file quand vous le décidez, et l'exécution réelle est portée par le cron (tâche email_send). Vous choisissez le rythme sans toucher au code.
- Interrupteur email.queue_enabled global
- Exécution déclenchée à chaque tick cron
- Coupure nette pour une fenêtre de maintenance
L'automatisme relance, vous restez maître de la file
Back-off, réclamation atomique et récupération travaillent en fond. Vous, vous gardez l'interrupteur, l'historique en base et la main sur le rythme d'envoi.
Questions fréquentes
Que se passe-t-il si un email échoue ?
Deux tâches cron peuvent-elles envoyer le même email en double ?
Comment mettre la file en pause ?
Que deviennent les envois bloqués si un worker s'arrête ?
Des emails qui partent, même quand tout ne part pas du premier coup
La mécanique de livraison & retry transforme un envoi fragile en pipeline qui insiste, se dédoublonne et se répare. Vous gardez l'interrupteur et la visibilité ; le back-off fait le reste.