Inbox transactionnelle
Une inbox transactionnelle utilise des enregistrements durables de messages pour protéger le traitement local contre les livraisons en double.
Une inbox transactionnelle utilise des enregistrements durables de messages pour protéger le traitement local contre les livraisons en double. Dans la variante décrite ici, la trace du traitement d’un message et sa modification métier sont enregistrées dans la même transaction de base de données.
Un service fictif dont le nom de consommateur est report-worker reçoit le message E-42. Il inscrit la combinaison du consommateur et de l’identifiant du message dans son inbox et fait passer un compteur de rapport de 6 à 7. Les deux changements sont validés ensemble. Une contrainte d’unicité en base sur cette combinaison protège aussi contre les instances qui travaillent simultanément. Vérifier d’abord, puis écrire ne suffit pas à lui seul.
Le moment de l’arrêt compte
Si la transaction échoue avant le commit, ni l’entrée d’inbox ni la modification du compteur ne persistent. Si le commit réussit mais que l’acquittement envoyé ensuite au broker se perd, E-42 peut arriver à nouveau. L’entrée existante empêche alors une nouvelle augmentation à 8. L’acquittement au broker ne fait pas lui-même partie de cette transaction locale.
L’idempotence décrit l’effet sûr d’une répétition ; l’inbox est un modèle possible pour l’obtenir. Une outbox enregistre les messages sortants avec la modification locale. L’inbox seule ne garantit pas qu’un appel HTTP externe soit exécuté ou qu’un e-mail soit envoyé exactement une fois. La conservation des identifiants doit couvrir la fenêtre possible de nouvelle livraison et de rejeu : des entrées supprimées trop tôt ne protègent plus contre les doublons tardifs.
Sources
Termes associés
- IdempotenceUne opération idempotente produit le même effet sur l’état, qu’elle soit exécutée une seule fois ou répétée à l’identique.
- Acquittement de messageUn acquittement indique au courtier de messages qu’une livraison a été reçue ou traitée selon la règle convenue.
- Délai aléatoire avant réessaiLe jitter fait varier aléatoirement les délais pour étaler les nouvelles tentatives de plusieurs clients.
- Espace client de testUn espace client logiquement délimité d’une application multilocataire, configuré pour les vérifications.
- Rejeu de webhookLe rejeu de webhook renvoie une notification déjà envoyée. La reprise volontaire et les attaques par rejeu nécessitent des contrôles différents.
- Clé d’idempotenceUne clé d’idempotence identifie les répétitions d’une même requête. Son effet dépend du périmètre, de la conservation et des règles de l’API.
Articles sur le sujet
Interfaces & intégration avec ASES
ERP, CRM et boutique bien connectés