Amazon ElastiCache for Valkey ahora admite durabilidad

Desde junio de 2026, Amazon ElastiCache for Valkey puede almacenar datos de forma duradera . Un clúster persiste las escrituras en distintas zonas de disponibilidad mediante un registro transaccional Multi-AZ. Esto le permite recuperar los datos ya persistidos después de un fallo de nodo o shard y actuar como almacenamiento de referencia para cargas de trabajo que no toleran pérdidas, en lugar de ser simplemente una caché delante de otro almacenamiento duradero.

El modo de escrituras síncronas garantiza que no se pierdan datos. El modo asíncrono mantiene la velocidad de una caché, pero deja expuesta a posibles pérdidas una ventana acotada de escrituras recientes. Eliges el modo al crear el clúster, según cuántos datos pueda permitirse perder tu carga de trabajo, qué tan rápidas deban ser sus escrituras y cómo deba comportarse cuando el sistema está bajo presión.

En este artículo te explico cómo cambia tu arquitectura cloud con esta nueva funcionalidad de ElastiCache for Valkey, cuáles son los costos y qué decisiones de arquitectura te permite tomar.

Amazon ElastiCache  se diseñó como una caché: rápida y con datos que puedes descartar. Los datos viven en memoria, una réplica y el failover automático se encargan de la disponibilidad, y cualquier dato perdido puede volver a obtenerse del sistema de referencia que está detrás. Esto funciona bien mientras exista otro almacenamiento duradero. Cualquier dato de ElastiCache puede perderse en cualquier momento, y deberías diseñar tu sistema con ese supuesto.

La principal desventaja de usar ElastiCache, o cualquier caché, es que pagas tres veces: una por el almacenamiento duradero, otra por ElastiCache y otra por la complejidad adicional de gestionar las escrituras en caché, los cache misses y la posibilidad de que un fallo completo del clúster sobrecargue el almacenamiento duradero.

A primera vista, la durabilidad te ofrece lo mejor de ambos mundos: un almacenamiento tan duradero como una base de datos convencional, con los tiempos de consulta de ElastiCache for Valkey y sin esa complejidad adicional. Las escrituras pasan por un registro transaccional Multi-AZ que sobrevive a fallos de nodos y shards. Así, incluso ante un fallo completo del clúster, los datos ya persistidos pueden recuperarse en lugar de perderse.

Esto amplía lo que puedes hacer con ElastiCache, aunque no lo convierte en una base de datos de propósito general. Sigue siendo un motor en memoria, con las mismas estructuras de datos y lecturas de microsegundos. La durabilidad es una propiedad que activas por clúster para los datos que necesitas conservar de forma duradera. Algunos ejemplos son las bases de conocimiento para RAG, la memoria de trabajo y de largo plazo de los agentes de IA, la tokenización de pagos, el inventario en tiempo real, el almacenamiento de sesiones y las tablas de clasificación.

Son datos cuya pérdida resulta inaceptable o costosa. Una caché con datos descartables como ElastiCache nunca estuvo pensada para ese caso de uso, hasta ahora.

La diferencia entre ambos modos se reduce a una decisión de tiempo: si el cliente recibe la confirmación de éxito antes o después de que la escritura se haya persistido. Ese orden determina la garantía de durabilidad, la latencia de escritura y el comportamiento del clúster bajo carga.

Las escrituras síncronas se persisten primero y se confirman después. El nodo primario escribe el cambio en el registro transaccional en al menos dos zonas de disponibilidad (AZs)  y solo entonces lo confirma al cliente. Cada escritura confirmada es duradera: si el nodo primario falla un instante después, la escritura se conserva en al menos otras dos AZs, y las lecturas desde el primario siguen reflejándola, incluso después de un failover a un nuevo nodo primario.

El costo en latencia es un viaje de ida y vuelta entre AZs por cada escritura, lo que aumenta la latencia de escritura de microsegundos a milisegundos de un solo dígito.

Las escrituras asíncronas se confirman primero y se persisten después. El primario aplica el cambio en memoria, devuelve una confirmación de éxito con la latencia habitual de microsegundos de ElastiCache y luego transmite la escritura al registro transaccional. Entre la confirmación y esa transmisión, la escritura solo existe en la memoria del nodo primario. Si este falla durante ese intervalo, la escritura se pierde. De esta forma, un fallo puede hacer que se pierdan hasta aproximadamente 10 segundos de escrituras confirmadas.

Las lecturas siguen teniendo latencias de microsegundos en ambos modos. La durabilidad no modifica la consistencia de lectura: son propiedades independientes. El primario ofrece consistencia fuerte con las escrituras síncronas, pero las réplicas tienen consistencia eventual en ambos modos y pueden ir por detrás de las últimas escrituras. Si tu carga escribe un estado y lo lee inmediatamente desde una réplica, algo habitual en RAG y en la memoria de agentes, puede seguir leyendo datos desactualizados incluso con la durabilidad activada.

 

En los benchmarks de latencia de AWS , las escrituras asíncronas tuvieron una diferencia de apenas microsegundos respecto de un clúster sin durabilidad. Con escrituras síncronas, las lecturas mantuvieron latencias de microsegundos con una carga moderada, y esa latencia solo aumentó a medida que crecía la concurrencia de escrituras.

La durabilidad asíncrona mantiene la latencia de escritura de microsegundos de un clúster sin durabilidad, con el mismo costo. Por eso, es una buena opción predeterminada si puedes aceptar que un fallo del nodo primario elimine los últimos 10 segundos de escrituras.

El nodo primario mide la antigüedad de la escritura más antigua que todavía no se ha guardado en el registro transaccional e informa ese valor a Amazon CloudWatch . Mientras ese retraso se mantenga por debajo de 10 segundos, las escrituras continúan normalmente. Cuando supera el umbral, por ejemplo, durante un pico de escrituras que provoca congestión transitoria en el registro transaccional, el primario deja de aceptar escrituras hasta ponerse al día y luego las reanuda automáticamente. Las lecturas siguen funcionando con latencias de microsegundos durante todo ese período.

Se espera que este estado de rechazo sea poco frecuente en la operación normal. Aun así, si eliges el modo asíncrono, necesitas aceptar una pausa breve y acotada de las escrituras bajo presión, y la posible pérdida de hasta 10 segundos de escrituras si hay un fallo, a cambio de la velocidad y el costo de una caché normal.

Tu backend debería estar preparado para gestionar los rechazos ocasionales de escrituras con reintentos automáticos y backoff exponencial. El cliente Valkey GLIDE lo hace automáticamente y, además, incorpora enrutamiento que tiene en cuenta las zonas de disponibilidad. Si tu flujo de escritura no puede tolerar ni siquiera una pausa breve, eso es un motivo para elegir escrituras síncronas.

Con las tres opciones sobre la mesa, sin durabilidad, asíncrona y síncrona, la elección se reduce a tres preguntas:

Seguir sin durabilidad es la opción adecuada cuando los datos son fáciles de reconstruir y las escrituras sin interrupciones importan más que la persistencia. Algunos ejemplos son las cachés read-through, los rate limiters y cualquier dato que puedas recalcular bajo demanda. El modo asíncrono cubre un amplio punto intermedio: reconstruir desde la fuente es lento o costoso, pero puedes reconciliar los datos si se pierden unos segundos de escrituras. El modo síncrono es para los casos en los que perder una sola escritura provoca un comportamiento incorrecto y puedes aceptar latencias de escritura de milisegundos de un solo dígito.

La durabilidad se elige al crear el clúster y no se puede desactivar. Después puedes cambiar un clúster duradero entre escrituras síncronas y asíncronas, pero no puedes añadir durabilidad a un clúster existente que no la tiene ni desactivarla una vez habilitada. Estos son los requisitos para habilitarla en un clúster nuevo:

La durabilidad está disponible en todas las regiones comerciales de AWS, las regiones de China y GovCloud (US), por lo que es poco probable que la cobertura regional te impida adoptarla.

Usar ElastiCache como almacenamiento duradero plantea una pregunta inmediata: ¿en qué se diferencia de Amazon MemoryDB, que AWS ya ofrece como una base de datos duradera en memoria? Ambos servicios tienen mucho en común, aunque elegir entre ellos depende de algo más que la durabilidad.

MemoryDB es una base de datos principal duradera en memoria, construida sobre el mismo tipo de registro transaccional Multi-AZ, con lecturas de microsegundos, escrituras de milisegundos de un solo dígito y nodos primarios con consistencia fuerte. Su modelo de durabilidad equivale, en la práctica, al modo síncrono de ElastiCache: cada escritura se persiste antes de confirmarse.

Lo que añade ElastiCache es la opción asíncrona: escrituras duraderas con latencia de microsegundos, a cambio de una ventana acotada de posible pérdida de datos. Si tu carga necesita persistencia sin sacrificar la velocidad de escritura, esa opción es nueva en esta familia de servicios. Más allá de eso, la elección depende de qué motor y funcionalidades se ajustan a tus necesidades, los requisitos de múltiples regiones y la ruta de migración.

El tipo de durabilidad que te conviene en ElastiCache depende de lo que tu carga de trabajo necesita y puede tolerar. Puedes seguir sin durabilidad cuando los datos sean fáciles y baratos de reconstruir y sea clave mantener las escrituras sin interrupciones. Te conviene activar la durabilidad en modo asíncrono cuando puedas recuperarte de la pérdida de unos segundos de datos, pero una reconstrucción completa sea costosa y puedas tolerar los reintentos de escritura.

Deberías elegir el modo síncrono cuando necesites garantizar la durabilidad de cada escritura confirmada y puedas aceptar latencias de escritura de milisegundos de un solo dígito. Lo que distingue las opciones es cuántos datos recientes puedes permitirte perder, qué tan rápidas deben ser las escrituras y cuánto afectan los reintentos a tu carga de trabajo.

Nota: Este artículo fue escrito originalmente en inglés, como parte de mi trabajo en Caylent. Yo soy el autor y tengo permiso explícito para reproducirlo en español en este medio. Puedes consultar el original aquí: https://caylent.com/blog/amazon-elasticachefor-valkey-now-supports-durability