Aller au contenu

Notes/temps réel · MongoDB · fiabilité

Une offre, une seule fois — l'idempotence dans l'écriture qui réclame le prix

Sur une enchère en direct, la question n'est pas « la requête a-t-elle réussi ? » mais « que répondre à celle qui revient ? ». Retour sur un choix de conception de Maison Dlala.

2026-11-12 · 2 min · Mohamed Abi

Un acheteur confirme une offre de 5 500. La requête part, le serveur l'accepte, puis le réseau tombe avant la réponse. Le navigateur ne sait pas si l'offre est passée. Il réessaie — peut-être sur une autre instance de l'API.

Que doit-il recevoir ?

Ce qui protégeait déjà, et ce qui manquait

Sur Maison Dlala, une offre était déjà acceptée par une seule mise à jour conditionnelle atomique sur la vente : le prix proposé doit dépasser le meilleur prix, la vente doit être ouverte, et l'horloge est celle du serveur. Un index unique empêchait de stocker deux fois la même offre. « Exécutée deux fois » était donc déjà impossible.

Mais la nouvelle tentative recevait un refus — montant trop bas, puisque le prix venait de monter… grâce à elle. Le client se voyait dire « refusé » pour une offre qui avait abouti. Et sans transactions multi-documents, un crash entre la réclamation du prix et l'enregistrement de l'offre pouvait laisser un prix monté sans offre correspondante.

Mettre la clé dans la même écriture

Chaque confirmation d'offre génère une clé côté navigateur. La tentation est de l'enregistrer après coup, dans une table de déduplication. Cela ne protège de rien : la fenêtre entre les deux écritures est exactement celle où les choses cassent.

La clé est donc enregistrée dans la même mise à jour atomique que le prix. La condition de la mise à jour vérifie à la fois que le prix est meilleur et que la clé n'a jamais été vue pour cet enchérisseur ; l'écriture place le nouveau prix et la clé ensemble. Une clé ne peut réclamer qu'une fois, sur n'importe quelle instance, puisque c'est la base qui tranche.

Répondre à la tentative qui revient

Quand une offre est refusée, le serveur regarde d'abord si sa clé a déjà réclamé le prix :

  • même clé, même montant : il renvoie le reçu d'origine — pas de seconde offre, pas de faux refus ;
  • même clé, autre montant : 409, réutilisation de clé refusée, même en concurrence ;
  • clé réclamée mais offre absente (le crash) : la situation est réglée à cette tentative.

Les anciens clients sans clé suivent l'ancien chemin, inchangé.

Ce que je retiens

La garantie doit vivre dans l'opération qui décide, pas autour. Redis transporte les événements entre instances, mais il ne décide rien : si Redis tombe, aucune offre n'est perdue ni dupliquée, parce que la vérité est dans une seule écriture MongoDB.

Le dépôt de Maison Dlala est privé ; cette note décrit le principe, pas le code.

L'étude de cas complèteMaison Dlala : des enchères en direct où le serveur a toujours raison →