La soumission de commandes en double est un problème classique d'idempotence qui peut survenir lors de doubles clics, de nouvelles tentatives réseau ou de la rediffusion de messages en file d'attente. Une solution robuste nécessite une approche en couches plutôt qu'un mécanisme unique. La première couche est le contrôle front-end, comme la désactivation des boutons après le premier clic, ce qui réduit les doublons accidentels mais n'est pas infaillible. La deuxième couche utilise un jeton distribué, généralement généré par le serveur et stocké dans Redis, qui doit être présenté avec chaque demande de commande et consommé de manière atomique. La troisième couche impose une contrainte unique sur la base de données, comme un numéro de commande métier, pour rejeter les doublons au niveau de la persistance. Enfin, un travail de réconciliation planifié peut détecter et résoudre les incohérences qui échappent aux autres couches. Pour les scénarios à forte concurrence, les opérations atomiques Redis et les scripts Lua sont essentiels pour garantir que la consommation de jetons et la création de commandes sont exemptes de conditions de course. Bien que l'article fournisse une implémentation Java AOP, les principes sous-jacents sont indépendants du langage et applicables à tout système distribué.
Un guide pratique pour éviter les soumissions de commandes en double grâce à une stratégie de défense en quatre couches, des contrôles front-end aux contraintes de base de données et à la réconciliation.