Prévoir les conflits
Documenter la réponse
La réponse de conflit doit rester stable et compréhensible. Elle peut demander une relecture avant nouvelle écriture. Suivez le taux de conflits et les retries pour détecter une interface ou un worker qui surcharge la ressource.
Vérifier la reprise
Testez timeout, retry, ordre inversé et arrêt du worker. Vérifiez qu’une création ne produit pas deux ressources et qu’une mise à jour refusée laisse l’état cohérent. Les logs doivent garder version et identifiant d’opération.
Appliquer la règle au serveur
Le serveur doit refuser une écriture lorsque la version envoyée ne correspond plus à la version stockée. Une simple comparaison côté navigateur ne protège pas l’API, car deux clients peuvent envoyer une demande en même temps. La réponse de conflit doit garder un statut prévisible et un identifiant de requête.
Pour les créations, une clé d’idempotence lie les retries à la même opération. Conservez cette clé pendant la durée nécessaire, puis expirez-la. Une contrainte unique en base protège aussi contre deux créations identiques, mais elle doit être accompagnée d’une réponse que le client comprend.
Tester les chemins difficiles
Lancez deux mises à jour sur la même ressource, interrompez la connexion après écriture et redémarrez un worker pendant son traitement. Vérifiez que la seconde opération ne remplace pas silencieusement la première et qu’un message peut être repris sans doubler son effet.
Utilisez des données fictives et un environnement isolé. Mesurez conflits, retries, latence et temps de résolution. Une hausse après un déploiement doit être reliée à la version, à l’interface ou au nombre de workers.
Aider le support
Le support doit voir l’identifiant de ressource, sa version, l’action demandée et le résultat. Il ne doit pas recevoir les données confidentielles qui ne sont pas nécessaires. Une procédure peut demander de relire l’état, de confirmer les champs modifiés et de relancer une seule opération.
Tester les reprises
Simulez timeout, retry, ordre inversé et arrêt du worker. Vérifiez qu’une création ne produit pas deux ressources et qu’une mise à jour refusée laisse l’état cohérent. Les tests utilisent des données fictives et un environnement isolé.
Informer le client
Un conflit doit être compréhensible et permettre de relire l’état. L’interface peut proposer de recharger ou de comparer les champs, tandis que l’API conserve la règle d’intégrité. Les logs corrélés doivent indiquer version et identifiant d’opération.
Suivre la tendance
Mesurez conflits, retries et temps de résolution. Une hausse peut venir d’une nouvelle interface, d’un worker supplémentaire ou d’un traitement trop long. Reliez l’alerte à une action documentée.
Une API peut utiliser version, horodatage contrôlé ou ETag. Le client renvoie cette valeur et reçoit un conflit lorsqu’elle a changé. La réponse doit permettre de relire l’état actuel et d’éviter un écrasement silencieux.
Les créations utilisent une clé d’idempotence lorsqu’un timeout peut provoquer un retry. Les mises à jour partielles limitent les champs concernés. Une opération longue peut créer une demande dans une file, puis vérifier la version avant écriture.
Les événements doivent contenir identifiant et version. Un consommateur en retard doit ignorer un événement ancien ou demander une resynchronisation. Suivez conflits, retries, temps de traitement et ressources disputées.
Testez écritures simultanées, ordre inversé, timeout et reprise du worker avec des données fictives. Les logs corrélés doivent expliquer la décision et le statut retourné au client.
Deux requêtes concurrentes peuvent modifier la même ressource et produire un résultat inattendu. Une API doit définir ce qui arrive lorsqu’un client lit, modifie et enregistre une donnée pendant qu’un autre client agit.
Identifier la version
Ajoutez un numéro de version, un horodatage contrôlé ou un ETag. Le client renvoie cette valeur lors de l’écriture. Si elle a changé, l’API renvoie un conflit que le client peut traiter.
Éviter les écrasements
Une mise à jour partielle réduit le risque lorsqu’elle modifie seulement les champs nécessaires. Les contraintes de base protègent les identifiants et les états incompatibles. Les opérations longues peuvent passer par une file.
Tester
Lancez deux écritures simultanées sur une donnée de test et vérifiez l’erreur, le journal et la réponse utilisateur. Les critères d’acceptation doivent inclure ce cas.
Sources : RFC 9110, conditional requests, MDN ETag.
Définir les conflits
Une réponse de conflit doit expliquer que la ressource a changé et permettre au client de relire l’état actuel. Évitez de fusionner automatiquement des champs lorsque cette décision peut modifier un montant, un statut ou une permission. Le support doit pouvoir retrouver l’identifiant de l’opération.
Les créations demandent une clé d’idempotence afin qu’un timeout ne crée pas deux ressources. Les mises à jour demandent une version ou une règle transactionnelle. Testez timeout, retry et ordre inversé des requêtes.
Mesurer
Suivez le taux de conflits, les retries et le temps passé à résoudre une opération. Une hausse peut venir d’une interface qui recharge trop tard ou d’un worker concurrent. Utilisez les logs corrélés pour distinguer les deux causes.