Votre file de messages garantit une livraison au moins une fois. Qu'est-ce que ça implique pour le consommateur que vous écrivez ?

Ça veut dire que les doublons sont normaux, pas exceptionnels, donc votre consommateur doit être idempotent. Dérivez une clé stable du message, enregistrez les clés traitées dans la même transaction que l'effet, et traitez une répétition comme une opération sans effet. Attendez-vous aussi à une livraison désordonnée et à une redistribution après un plantage entre le travail et l'accusé de réception. Le exactly once de bout en bout n'existe pas entre systèmes ; vous avez du at least once plus un traitement idempotent.

Ça veut dire que je recevrai le même message deux fois, en général parce que le consommateur a fait le travail puis est mort avant d'accuser réception, donc le broker le redistribue. Le consommateur doit donc pouvoir tourner deux fois sans risque avec la même entrée. En pratique, je prends un identifiant stable dans le message, et quand j'écris l'effet j'écris l'identifiant traité dans la même transaction de base de données, avec une contrainte d'unicité. Si l'insertion entre en conflit, je sais que j'ai déjà traité et j'accuse réception sans refaire le travail. Le point critique, c'est que l'enregistrement de déduplication et l'effet soient validés ensemble ; si je les écris séparément, il existe une fenêtre où je peux dupliquer. Je suppose aussi que l'ordre n'est pas garanti, donc les gestionnaires sont écrits pour tolérer une mise à jour arrivant avant la création, en général en clé sur l'entité avec une vérification de version. Pour les échecs, j'utilise une reprise bornée avec backoff exponentiel et jitter, puis une file de messages morts avec une alerte, parce que réessayer indéfiniment un message empoisonné en silence, c'est comme ça qu'une file se bouche pendant la nuit.