Exactly-once n'existe pas : ce qu'on vous vend à la place

Un consommateur reçoit un message, exécute un effet, puis acquitte. Il n'existe que deux ordres possibles pour ces deux derniers gestes, et chacun a sa panne.

Effet puis acquittement :
  1. recevoir
  2. exécuter l'effet
  3. acquitter          ← crash avant : le message revient, l'effet est doublé

Acquittement puis effet :
  1. recevoir
  2. acquitter
  3. exécuter l'effet   ← crash avant : le message est parti, l'effet est perdu

Il n'y a pas de troisième ordre. Tant que l'effet et l'acquittement vivent dans deux systèmes différents, aucun protocole ne les rend atomiques ; on retrouve la double écriture, vue du côté du consommateur. Le choix se fait donc entre « au plus une fois » et « au moins une fois ». « Exactement une fois », en tant que garantie de livraison, n'est pas dans la liste.

Le terme figure pourtant sur la documentation de la plupart des brokers. Ce n'est pas un mensonge, c'est un glissement de périmètre, et il faut savoir lire lequel.

Ce que la promesse couvre réellement

Sous l'étiquette « exactly-once », on trouve des mécanismes distincts.

La déduplication à la production. Le producteur attache un identifiant à chaque message, et le broker écarte les doublons reçus dans une fenêtre de temps. Cela protège contre un producteur qui relance un envoi dont il n'a pas reçu l'accusé. Cela ne dit rien de ce qui se passe après la livraison au consommateur, et la protection cesse dès que le rejeu arrive hors de la fenêtre.

La transaction interne au broker. On lit un message, on en produit d'autres et on avance sa position de lecture, le tout de façon atomique. La garantie est réelle, mais elle porte sur des opérations qui restent dans le broker. Si votre traitement lit un topic et écrit dans un autre topic du même cluster, il s'exécute bien exactement une fois. Dès qu'il écrit dans PostgreSQL ou appelle une API, la transaction du broker ne couvre plus cet effet.