Une file d’attente sépare la réception d’une demande de son traitement. Elle absorbe les pics et permet de reprendre certaines opérations, mais elle exige des règles pour les retries, les doublons et les messages bloqués.
Définir le contrat du message
Chaque message doit indiquer l’opération, l’identifiant de la ressource et la version du format. Ajoutez un identifiant d’opération pour reconnaître une livraison répétée. Ne mettez pas dans le message une donnée sensible qui n’est pas nécessaire au traitement.
Documentez qui produit le message, quel worker le consomme et ce qui arrive lorsque la ressource n’existe plus. Une évolution du format doit rester compatible pendant la période où plusieurs versions de workers tournent ensemble.
Rendre le traitement rejouable
Un worker peut terminer son action puis perdre la connexion avant de confirmer le message. Le système peut alors livrer le même message. Utilisez une clé d’idempotence ou une contrainte adaptée pour éviter une seconde écriture indésirable.
L’idempotence ne corrige pas une opération qui dépend de plusieurs systèmes sans coordination. Journalisez les étapes et prévoyez une réconciliation pour les cas où un service externe a accepté l’action mais où la confirmation n’est pas revenue.
Régler les retries
Un message temporairement impossible peut être retenté avec un délai progressif. Limitez le nombre d’essais et ajoutez une variation pour éviter que tous les workers réessaient au même instant. Une erreur de validation définitive doit aller vers une file d’exception plutôt que bloquer indéfiniment.
La file d’exception doit être surveillée. Conservez le message, la cause et le nombre d’essais sans exposer un secret dans le tableau de bord. Une personne doit pouvoir corriger la cause puis relancer l’opération selon une procédure vérifiable.
Mesurer l’âge et la capacité
Surveillez le nombre de messages, leur âge, le taux d’erreur et le temps de traitement. Une file vide ne signifie pas que le système est sain si les producteurs échouent avant de publier. Comparez les métriques du producteur, du broker et du worker.
L’autoscaling doit utiliser un signal lié à la file. Vérifiez que l’ajout de workers ne surcharge pas la base ou le service externe. Le guide sur l’autoscaling cloud traite ces limites.
Arrêter proprement
Lors d’un déploiement, un worker doit terminer ou rendre son message selon les garanties du système. Une interruption brutale peut provoquer un doublon ou augmenter le délai de traitement. Ajoutez un délai de fermeture et observez les messages en cours.
Testez l’arrêt pendant une charge représentative. Vérifiez que les nouvelles versions et les anciennes comprennent les messages présents dans la file. Un retour arrière du code doit connaître la compatibilité des messages déjà publiés.
Préparer un incident
Le runbook doit indiquer comment ralentir un producteur, isoler un type de message, augmenter temporairement un worker et examiner la file d’exception. Notez les commandes avec l’environnement ciblé et les droits requis. Une action qui supprime une file demande une validation et une sauvegarde si elle est possible.
Sources : AWS, message ordering and retries, Google Cloud, reliable task processing.