ReplicatedWriteConflictException

TL;DR: Escribiste en un elemento en una tabla global de consistencia fuerte de múltiples regiones (MRSC) mientras una solicitud en otra Región estaba modificando el mismo elemento. La fuerte coherencia entre varias regiones no puede permitir que se obtengan ambas victorias, por lo que se rechaza una escritura. AWS lo documenta como reintentable: retroceda y vuelva a intentarlo, y reduzca la contención entre regiones en elementos importantes siempre que pueda.

Qué significa

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

Las tablas globales clásicas (con consistencia eventual) aceptan escrituras concurrentes en todas partes y luego las reconcilian con la política de "gana quien escribe último". Las tablas globales MRSC hacen el intercambio opuesto: una escritura debe coordinarse entre Regiones antes de reconocerse, así que dos Regiones modificando el mismo Item en el mismo momento es un conflicto genuino — y una de las partes recibe esta excepción en lugar de una sobrescritura silenciosa.

Por qué ocurre

El mismo Item se escribe desde varias Regiones de forma concurrente — dos despliegues de aplicación tratando ambos el Item como suyo para actualizar.
Un Item de coordinación caliente — contadores, bloqueos o Items de configuración singleton tocados por cada Región son imanes naturales de conflictos.
Tormentas de reintentos entre Regiones — reintentos simultáneos de la misma operación lógica desde diferentes Regiones que se siguen colisionando.

Cómo solucionarlo

Reintenta con backoff exponencial y jitter — el conflicto es momentáneo; una vez que la escritura de la otra Región se completa, el reintento procede. AWS marca este error como reintentable:
```
// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}
```
Da a los Items una Región de origen — enruta las escrituras de una clave dada a través de una sola Región (por residencia del usuario, tenant o partición), manteniendo las demás Regiones mayormente de lectura. La contención desaparece cuando solo una Región muta un Item.
Haz que las actualizaciones concurrentes sean conmutativas — las actualizaciones de contador atómicas (ADD / SET x = x + :n) sobre atributos separados entran en conflicto menos que los ciclos leer-modificar-escribir sobre el Item completo.
Vuelve a comprobar la intención tras perder la carrera — la otra Región cambió el Item; un reintento condicional (ConditionExpression sobre un atributo de versión) garantiza que tu escritura sigue siendo válida frente al nuevo estado.
Enruta los Items de coordinación calientes por una sola Región. Los bloqueos, los contadores y los blobs de configuración escritos desde todas las Regiones son la fuente habitual de conflictos.

Inspecciónalo en DynoTable

Compara el mismo Item entre Regiones después de un conflicto — cambia con ⌘P, abre la tabla con ⌘K y lee el Item en cada Región de réplica lado a lado. El área de preparación (⌘S) te permite montar un reintento condicional y revisar el diff antes de confirmarlo.

Estima el coste de las escrituras replicadas con la calculadora de precios antes de habilitar MRSC en una tabla caliente. Configura cada Región en Ajustes → Perfiles con Test Connection. Consulta Conectar con AWS e Instalación.

Fuentes

How DynamoDB global tables work (verificado el 2026-07-13)
Error handling with DynamoDB (verificado el 2026-07-13)

Errores relacionados

TransactionConflictException — la prima de una sola Región: una transacción en curso posee el Item.
La versión de la tabla global no coincide
ReplicaAlreadyExistsException
Aprende: DynamoDB global tables

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.