ReplicatedWriteConflictException

TL;DR — Escribiste en un Item de una tabla global multi-Región con consistencia fuerte (MRSC) mientras una petición en otra Región estaba modificando el mismo Item. La consistencia fuerte multi-Región no puede dejar que aterricen ambas ganadoras, así que una de las escrituras se rechaza. AWS lo documenta como reintentable: aplica backoff y reintenta, y reduce la contención entre Regiones sobre Items calientes donde puedas.

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.

Observar cómo cambia un Item entre Regiones es mucho más fácil con los datos delante — la aplicación de escritorio DynoTable se conecta a cada Región de réplica para que compares el Item lado a lado, y la calculadora de precios de DynamoDB estima cuánto cuestan las escrituras replicadas.

Errores relacionados

TransactionConflictException — la prima de una sola Región: una transacción en curso posee el Item.
Global table version mismatch
ReplicaAlreadyExistsException
Aprende: DynamoDB global tables

References

Última verificación el 2026-07-13 con la documentación oficial de AWS enlazada arriba.