Lecturas fuertemente consistentes vs eventualmente consistentes en DynamoDB
Actualizas un elemento, lo vuelves a leer inmediatamente y obtienes el valor antiguo. La escritura tuvo éxito — un instante después la misma lectura devuelve el valor nuevo. Nada está roto: has topado con la lectura eventualmente consistente que DynamoDB usa por defecto, y puedes optar por no usarla en cada solicitud.
Esta es una de las pocas perillas de corrección que DynamoDB pone directamente en tus manos, y tiene un precio real asociado. Acertar con ella significa saber qué garantiza cada modo, cuánto cuesta y dónde las lecturas fuertes sencillamente no están disponibles.
¿Cuál es la diferencia entre las lecturas fuertemente consistentes y las eventualmente consistentes en DynamoDB?
Una lectura eventualmente consistente (la opción por defecto) la atiende cualquier réplica, así que puede devolver brevemente datos obsoletos justo después de una escritura, pero cuesta la mitad. Una lectura fuertemente consistente, activada por solicitud con ConsistentRead=true, se enruta al líder de la partición y siempre refleja toda escritura confirmada — al doble de la capacidad de lectura.
- Eventualmente consistente (por defecto) — puede devolver brevemente datos obsoletos justo después de una escritura. El modo de lectura más barato.
- Fuertemente consistente — siempre refleja toda escritura confirmada antes de la lectura.
Actívalo por solicitud con
ConsistentRead=true. - Las lecturas fuertes cuestan 2× las eventuales. Una lectura fuertemente consistente consume el doble de capacidad de lectura que una eventualmente consistente para los mismos datos.
- No en todas partes. Tienes lecturas fuertes en la tabla base y en un índice secundario local. Un índice secundario global es solo eventual — sin opción de activarlo.
- Usa eventual por defecto. Recurre a fuerte solo cuando leas tus propios datos recién escritos y un instante de obsolescencia sería incorrecto.
El problema: una lectura que no ve la última escritura
Digamos que gestionas cuentas de usuario. Un usuario cambia su correo de notificaciones, tu app escribe la actualización, y la pantalla de confirmación vuelve a leer inmediatamente el perfil para mostrar la nueva dirección. Con el modo de lectura por defecto, esa relectura puede caer en una réplica que todavía no ha recibido el cambio — así que el usuario ve su correo antiguo y asume que el guardado falló.
La ventana es pequeña (normalmente bastante menos de un segundo) y se cierra por sí sola. Pero "casi siempre correcto" no es suficiente para una confirmación de lectura-tras-escritura. Ese es exactamente el caso para el que existe la consistencia fuerte.
Por qué ocurre la consistencia eventual
DynamoDB almacena cada partición en tres nodos de almacenamiento — uno primario y dos réplicas — repartidos en zonas de disponibilidad distintas. Una escritura se reconoce una vez que aterriza en el primario y una réplica; luego se propaga al tercer nodo de forma asíncrona.
Las lecturas, para repartir la carga, pueden ser atendidas por cualquiera de los tres nodos. Una lectura eventualmente consistente puede caer en un nodo que todavía no ha recibido tu escritura más reciente — así que devuelve un valor ligeramente obsoleto. Una lectura fuertemente consistente se enruta al líder de la partición, que siempre tiene los últimos datos confirmados, así que nunca devuelve resultados obsoletos.
Ese retraso de replicación es toda la diferencia. También explica el coste de 2×: las lecturas fuertes no pueden repartirse entre réplicas como sí pueden las eventuales, así que DynamoDB las cobra al doble de capacidad.
El coste, hecho concreto
Las lecturas se miden en unidades de capacidad de lectura (RCU), cada una cubriendo hasta 4 KB.
Una RCU compra una lectura fuertemente consistente o dos lecturas eventualmente
consistentes de un elemento de 4 KB. Así que activar ConsistentRead=true en una ruta de
lectura caliente duplica su coste de lectura — en un endpoint de mucho tráfico eso es una partida
que notarás.
Modela la diferencia para tus propios tamaños de elemento y tasas de solicitud con la calculadora de precios de DynamoDB antes de hacer de las lecturas fuertes tu opción por defecto — rara vez vale la pena pagar el doble en todos los casos.
Dónde están (y no están) disponibles las lecturas fuertes
| Lectura contra | ¿Fuertemente consistente? |
|---|---|
| Tabla base | Sí — actívalo con ConsistentRead=true |
| Índice secundario local (LSI) | Sí — misma activación que la tabla base |
| Índice secundario global (GSI) | No — solo eventual, sin anulación |
Un GSI mantiene su propia copia de los datos, replicada de forma asíncrona desde la tabla base, así que nunca puede ofrecer una lectura fuerte. Si un patrón de acceso necesita genuinamente lectura-tras-escritura y planeabas atenderlo desde un GSI, esa es una señal para atenderlo desde la tabla base o un LSI en su lugar.
Trampas y próximos pasos
- No hagas de las lecturas fuertes la opción por defecto. La mayoría de las lecturas toleran una ventana de obsolescencia de menos de un segundo; pagar 2× en todas partes es gasto desperdiciado.
- No esperes lectura-tras-escritura de un GSI. Es eventual por diseño — consulta por qué un GSI es eventualmente consistente.
- Las transacciones leen de forma fuerte.
TransactGetItemssiempre es fuertemente consistente — consulta transacciones de DynamoDB. - La consistencia interactúa con la capacidad. El multiplicador de 2× se conecta directamente con la planificación de costes de on-demand vs provisioned.
¿Quieres explorar tus tablas e índices de DynamoDB sin escribir llamadas a la API? Descarga DynoTable e inspecciona tus datos directamente.