Plusieurs serveurs, une table : résolution de conflits côté commande

Lors d'un banquet de 1200 couverts à Antalya Belek, quatre serveurs ajoutent simultanément des plats sur la même table ronde de 20 personnes. Le comportement "last-write-wins" écrase silencieusement 14 articles. Voici comment nous avons mis en production le verrouillage optimiste, le 409 Conflict et le pattern de retry.

Pourquoi last-write-wins ne suffit pas

Un UPDATE orders SET items = ? WHERE id = ? banal n'enregistre que le dernier commit. Quatre POST en 200 ms et seuls 6 articles sur 20 atteignent la cuisine.

La parade : une colonne version par ligne. Le client la lit à l'ouverture, la renvoie à l'écriture, et le serveur vérifie de manière atomique.

Verrouillage optimiste avec versioning

Ajoutez version INTEGER et updated_at. Le PATCH :

• Client : { items, expected_version: 7 }.
• Serveur : UPDATE ... WHERE id = ? AND version = 7.
• 0 ligne affectée → 409 Conflict + état actuel.

409 Conflict + fusion côté client

Pas d'auto-retry. Le client affiche la commande à jour, surligne les ajouts/retraits prévus et attend la confirmation. À Belek, le taux ressenti de conflit est passé de 0,4 % à 0 %.

Couplez-le à un log append-only order_events pour auditer qui a fait quoi et quand.

FAQ

Pourquoi pas SELECT FOR UPDATE ? Cela sérialise les serveurs et nuit au débit.

Compatible D1 ? Oui, UPDATE atomique sur INTEGER, sans anti-pattern.

Et hors ligne ? File locale + expected_version, fusion à la reconnexion.

Cet article vous a été utile ? Partagez-le.