Transactions e-commerce : isolation, interblocages et reprise sûre

Intégrer la concurrence au parcours e-commerce

Le paiement, la réservation du stock, l’utilisation d’un coupon et la confirmation du paiement peuvent toucher les mêmes données en quelques millisecondes. Une transaction regroupe les opérations, mais leur ordre reste soumis au niveau d’isolation, aux accès et au moteur. Commencez par l’invariant métier : une quantité ne doit pas devenir négative, un coupon à usage unique ne doit pas être consommé deux fois et une commande ne doit pas atteindre des états incompatibles.

Documentez cet invariant et les requêtes qui peuvent le modifier. Incluez les lectures qui déclenchent une décision : une lecture apparemment anodine peut voir un état permis par le niveau choisi, mais insuffisant pour le parcours. La bonne question n’est pas « utilisons-nous des transactions ? », mais « quelles anomalies acceptons-nous et quel coût assumons-nous pour prévenir les autres ? »

Conserver une frontière courte et complète

La frontière doit contenir les modifications qui réussissent ou échouent ensemble, tout en excluant les appels réseau, le rendu et les calculs inutiles. Une transaction longue accroît la contention et les attentes. Préparez les entrées, ordonnez les lectures et écritures essentielles, puis validez ou annulez avant de répondre.

Choisir l’isolation selon l’anomalie à empêcher

Les niveaux portent des noms similaires, mais leur comportement concret varie entre PostgreSQL, MySQL et SQL Server. Documentez le moteur, la version, la configuration et le mode d’accès. Pour chaque flux, modélisez des séquences concurrentes : deux paniers achètent la dernière unité, une demande de remboursement se superpose à la capture du paiement, ou la réconciliation lit pendant qu’une commande change. Vérifiez si une décision peut s’appuyer sur des lectures incohérentes, perdre une mise à jour ou dépendre d’un état qui ne reste pas valide jusqu’au commit.

Ne choisissez pas le niveau le plus fort par réflexe et ne le réduisez pas seulement pour gagner du temps. Une isolation renforcée peut convertir certaines anomalies en annulations à rejouer. Un niveau plus faible peut exiger des contraintes, des mises à jour conditionnelles ou des verrous explicites soigneusement conçus. Ce choix est un contrat applicatif à prouver par des tests de concurrence, pas un simple réglage global.

Employer contraintes et comparaisons atomiques

Les contraintes d’unicité, les clés étrangères et les prédicats de mise à jour défendent les invariants au plus près des données. Une mise à jour exécutée seulement si la version et l’état correspondent encore aux valeurs lues transforme une course en résultat observable. Vérifiez toujours le nombre de lignes affectées et interprétez zéro ligne comme un conflit, jamais comme un succès silencieux. Le mécanisme précis dépend du moteur et doit être testé sur le schéma réel.

Distinguer interblocage, blocage et délai dépassé

Lors d’un blocage, une transaction attend une ressource détenue par une autre ; l’attente peut se résoudre quand le détenteur termine. Un interblocage forme un cycle où chaque participant attend une ressource détenue par un autre. Le moteur choisit une transaction victime et l’annule pour rompre ce cycle, mais la sélection et le diagnostic changent selon le produit. Un dépassement de délai est encore différent : il indique qu’une limite temporelle est atteinte et ne prouve pas, à lui seul, l’existence d’un interblocage.

Classez les erreurs avec les codes documentés du pilote, jamais par le texte traduit du message. Enregistrez l’identifiant transactionnel applicatif, l’opération, la tentative, la durée, la phase et le code du moteur sans exposer de données sensibles. Mesurez séparément les interblocages, les longues attentes, les délais dépassés et les échecs de sérialisation. Les regrouper sous « erreur de base de données » masque des remèdes différents.

Réduire les cycles avec un ordre d’accès prévisible

Lorsque plusieurs flux modifient des commandes, des lignes de stock et des paiements, faites acquérir les ressources dans le même ordre logique. Gardez des requêtes sélectives, des index adaptés aux prédicats et des lots bornés, car un accès large touche davantage de lignes et retient les ressources plus longtemps. Cette discipline réduit les cycles, sans garantir leur disparition. L’application doit toujours gérer le résultat prévu par la documentation du moteur.

Reproduisez les conflits avec des tests qui synchronisent deux sessions sur des étapes définies. Les pauses aléatoires seules peuvent manquer l’ordonnancement critique. Contrôlez l’ordre des requêtes, les index choisis et les plans, puis répétez après changement de schéma ou de version. Un plan différent peut modifier l’ordre physique des accès alors que le code semble identique.

Rejouer toute la transaction, pas la dernière instruction

Après un interblocage ou un échec de sérialisation, les données lues auparavant ne constituent plus une base fiable. Une reprise correcte recommence : elle ouvre une nouvelle transaction, relit les données, recalcule la décision et exécute toutes les écritures avant une nouvelle validation. Rejouer uniquement la dernière requête peut combiner une ancienne décision avec un nouvel état et violer l’invariant que la transaction devait défendre.

Borner tentatives, durée et pression

Ne rejouez que les erreurs classées transitoires. Fixez un nombre maximal de tentatives, un budget de temps global et des pauses croissantes assorties d’une variation aléatoire, puis renvoyez un état explicite lorsque le budget est épuisé. Une boucle infinie transforme la contention en saturation et allonge la file du passage en caisse. Mesurez les tentatives et arrêtez plus tôt si la requête cliente a expiré ou si le service est surchargé.

L’enveloppe de reprise doit recevoir une fonction transactionnelle complète et ne conserver aucun objet provenant de la tentative précédente. Chaque itération recrée la connexion ou le contexte selon le pilote, applique les mêmes limites et produit un seul résultat. Testez aussi l’épuisement : l’appelant doit savoir proposer une nouvelle action, placer le travail en file ou afficher une erreur récupérable.

Protéger les effets que l’annulation ne retire pas

L’annulation de la transaction en base n’annule ni l’envoi d’un courriel, ni l’envoi d’une demande au prestataire de paiement, ni la publication d’un message, ni l’écriture d’un fichier. Si ces effets se trouvent dans le bloc rejouable, chaque tentative peut les dupliquer. Enregistrez l’intention dans la base, utilisez un identifiant d’idempotence stable et déclenchez l’envoi après validation par un processus fiable. Si l’appel externe est inévitable, appliquez le contrat d’idempotence du service et conservez le lien entre demande et résultat.

Distinguez l’échec avant le commit, le commit réussi avec une réponse perdue et l’échec de l’effet ultérieur. Ce sont des états différents qui exigent une réconciliation, pas une reprise aveugle. Une outbox transactionnelle peut enregistrer la modification métier et l’intention de publier dans la même transaction, mais la livraison suit une sémantique « au moins une fois » et peut donc produire des doublons que le consommateur doit tolérer.

Observer et déployer sans seuil universel inventé

Établissez une référence pour votre charge : le taux de transactions conclues, les échecs par classe, le nombre moyen de tentatives ainsi qu’un percentile élevé ou le maximum observé, le temps d’attente, la durée totale et les opérations qui épuisent le budget. Reliez ces mesures à la version applicative, à l’empreinte de requête et au plan sans exposer de valeurs personnelles. Une hausse des reprises peut venir du trafic, d’un nouvel ordre d’accès ou d’un index devenu inadéquat ; cherchez la corrélation plutôt qu’un chiffre universel.

Déployez une modification à la fois sur une part contrôlée du trafic. Préparez le retour arrière du code, du schéma et de la configuration, et conservez un test concurrent déterministe dans la CI. Pour concevoir des frontières transactionnelles, une observabilité et une reprise adaptées à votre boutique, découvrez nos services pour les systèmes numériques et l’e-commerce. Le but n’est pas de nier les conflits, mais de les rendre prévus, bornés et vérifiables.