ReplicatedWriteConflictException

TL;DR — Tu as écrit dans un élément d'une table globale multi-Région fortement cohérente (MRSC) pendant qu'une requête dans une autre Région modifiait le même élément. La forte cohérence multi-Région ne peut pas laisser les deux gagner, donc une écriture est rejetée. AWS la documente comme réessayable : fais un backoff et réessaie, et réduis la contention inter-Région sur les éléments chauds là où tu peux.

Ce que ça signifie

ReplicatedWriteConflictException: One or more items in this request are
being modified by a request in another Region.

Les tables globales classiques (à cohérence à terme) acceptent des écritures concurrentes partout et les réconcilient ensuite en last-writer-wins. Les tables globales MRSC font le compromis inverse : une écriture doit être coordonnée entre les Régions avant d'être acquittée, donc deux Régions modifiant le même élément au même instant est un vrai conflit — et un côté reçoit cette exception au lieu d'un écrasement silencieux.

Pourquoi ça arrive

Le même élément est écrit depuis plusieurs Régions simultanément — deux déploiements d'application traitant tous deux l'élément comme le leur à mettre à jour.
Un élément de coordination chaud — compteurs, verrous ou éléments de config singleton touchés par chaque Région sont des aimants à conflits naturels.
Tempêtes de reprises entre Régions — des reprises simultanées de la même opération logique depuis différentes Régions continuent de se percuter.

Comment le corriger

Réessaie avec un backoff exponentiel et du jitter — le conflit est momentané ; une fois l'écriture de l'autre Région terminée, la reprise passe. AWS marque cette erreur comme réessayable :
```
// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}
```
Donne aux éléments une Région d'origine — route les écritures d'une clé donnée à travers une seule Région (par résidence de l'utilisateur, tenant ou partition), en gardant les autres Régions surtout en lecture. La contention disparaît quand une seule Région mute un élément.
Rends les mises à jour concurrentes commutatives — les mises à jour de compteur atomique (ADD / SET x = x + :n) sur des attributs distincts entrent moins en conflit que les cycles read-modify-write sur l'élément entier.
Revérifie l'intention après avoir perdu la course — l'autre Région a modifié l'élément ; une reprise conditionnelle (ConditionExpression sur un attribut de version) garantit que ton écriture est toujours valide contre le nouvel état.

Observer un élément changer à travers les Régions est bien plus facile avec les données sous les yeux — l'application desktop DynoTable se connecte à chaque Région réplica pour que tu compares l'élément côte à côte, et le calculateur de tarifs DynamoDB estime ce que coûtent les écritures répliquées.

Erreurs liées

TransactionConflictException — la cousine mono-Région : une transaction en cours possède l'élément.
Global table version mismatch
ReplicaAlreadyExistsException
En savoir plus : DynamoDB global tables

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.