Módulo 4: Domain 3 High Performing Architectures
4. Task 3.3: bases de datos de alto rendimiento
Descripción
aws-core-services-guide Módulo 7 construyó Shipments de verdad — tabla, partition key, y los dos modos de capacidad (on-demand vs. aprovisionado), con RCU y WCU definidas con precisión. Esa misma guía, en su primera lección, nombró explícitamente a DAX como parte de "el modelado de acceso avanzado de DynamoDB... que vive en las guías hermanas del ecosistema AWS Cloud" — una frontera declarada, nunca una promesa de cobertura. Esta lección es esa guía hermana: la primera vez que DAX, ElastiCache y el concepto formal de read replica se enseñan de verdad en todo este ecosistema. El task statement oficial los nombra con precisión: "caching strategies and services (for example, Amazon ElastiCache)... database replication (for example, read replicas)... database types and services (for example, serverless, relational compared with non-relational, in-memory)".
Conexión con el módulo
Vas a reconocer Shipments y sus dos modos de capacidad de aws-core-services-guide Módulo 7, lección 6 — pero esta vez con dos piezas nuevas montadas encima: un caché en memoria (ElastiCache, para bases de datos relacionales o de propósito general) y un caché específico de DynamoDB (DAX), cada uno resolviendo un problema de rendimiento distinto.
Amazon ElastiCache: dos motores, un mismo principio
ElastiCache es un almacén de datos en memoria que se sitúa entre tu aplicación y tu base de datos — ninguna guía hermana de este ecosistema lo construyó jamás, porque ninguna tuvo un problema de lecturas repetidas lo bastante intenso para justificarlo. La documentación oficial de AWS ofrece dos motores, con capacidades muy distintas entre sí:
| ElastiCache for Valkey (compatible con Redis OSS) | ElastiCache for Memcached | |
|---|---|---|
| Estructuras de datos | Strings, listas, sets, sorted sets, hashes, bit arrays, HyperLogLog | Solo clave-valor simple |
| Persistencia | Sí — snapshots de punto en el tiempo | No — caché puro, sin persistencia |
| Replicación | Sí — réplicas de un nodo primario, para lectura y resiliencia | No — sin replicación nativa |
| Pub/Sub | Sí | No |
| Arquitectura | Un solo hilo por nodo | Multi-hilo — escala aprovechando varios núcleos por nodo |
| Caso de uso | Estructuras de datos avanzadas, leaderboards, scripting con Lua, caché con persistencia | Simplicidad, escalado horizontal sencillo, caché de objetos sin lógica compleja |
Una honestidad de nomenclatura, verificada al momento de escribir esta lección: AWS creó Valkey como un fork de código abierto de Redis después de un cambio de licencia del proyecto original, y hoy lo presenta como el motor recomendado, compatible con el mismo protocolo y comandos que Redis OSS. Vas a ver ambos nombres —"ElastiCache for Redis" en material de examen más antiguo, "ElastiCache for Valkey" en la documentación actual— refiriéndose, en la práctica, al mismo motor con las mismas estructuras de datos y capacidades descritas en esta tabla.
La decisión de examen, en una frase: si el escenario necesita estructuras de datos complejas, persistencia o Pub/Sub, la respuesta es Valkey/Redis OSS. Si el escenario pide explícitamente simplicidad y escalar el caché horizontalmente entre varios núcleos, sin necesitar nada más que clave-valor, Memcached es la respuesta más ajustada — y con frecuencia la más económica.
Estrategias de caché: cache-aside y write-through
El task statement nombra "caching strategies" como conocimiento explícito, no solo el servicio. La documentación oficial de AWS describe dos patrones fundamentales, cada uno con una relación distinta entre la aplicación, el caché y la base de datos:
Cache-aside (también llamado lazy loading)
La aplicación consulta el caché primero. Si el dato está ahí (cache hit), lo devuelve de inmediato. Si no está (cache miss), la aplicación consulta la base de datos, y ella misma escribe el resultado en el caché antes de devolverlo — de modo que la siguiente lectura del mismo dato sea un cache hit.
CACHE-ASIDE (LAZY LOADING) — SOLO SE CACHEA LO QUE DE VERDAD SE PIDE
1. App pregunta al caché ──▶ 2a. HIT: caché responde directo
└─▶ 2b. MISS: caché responde vacío
│
▼
3. App consulta la base de datos
│
▼
4. App escribe el resultado en el caché
│
▼
5. App devuelve el datoVentajas, según la documentación oficial: solo se cachea lo que realmente se solicita (nunca se llena el caché con datos que nadie pide), y la falla de un nodo de caché no es fatal — el siguiente cache miss simplemente consulta la base de datos y repuebla el caché. Desventajas: cada cache miss implica tres viajes (caché, base de datos, escritura al caché) en vez de uno solo, y los datos pueden quedar obsoletos (stale) si la base de datos cambia sin que nadie vuelva a leer —y por lo tanto repoblar— esa clave específica.
Write-through
Cada vez que la aplicación escribe en la base de datos, escribe también, en la misma operación, al caché — el caché nunca está desactualizado, porque se actualiza en el mismo momento que el dato de origen cambia.
WRITE-THROUGH — EL CACHÉ NUNCA ESTÁ DESACTUALIZADO
1. App escribe en la base de datos
│
▼
2. App escribe el mismo dato en el caché (misma operación lógica)
│
▼
3. Confirmación de éxitoVentajas: los datos en el caché nunca están obsoletos. Desventajas: cada escritura implica dos viajes (base de datos, caché) en vez de uno — una penalización de escritura, no de lectura, que los usuarios suelen tolerar mejor (una actualización "se siente" como si debiera tomar más tiempo que una lectura); y si un nodo nuevo entra al clúster (por falla o por escalado), empieza vacío hasta que algo lo actualice explícitamente, un problema que se puede mitigar combinando write-through con cache-aside.
TTL (time to live), la pieza que resuelve la desventaja de cada estrategia: asignarle a cada clave del caché un tiempo de expiración limita cuánto puede envejecer un dato de cache-aside (fuerza una relectura periódica de la base de datos) y reduce el "ruido" de un caché write-through que acumula datos que nadie vuelve a leer.
La decisión de examen: un escenario que describe una carga con muchas lecturas repetidas sobre un subconjunto pequeño de datos ("hot keys" — el ejemplo clásico: un producto en oferta de un día, consultado miles de veces más que el resto del catálogo), donde cierta obsolescencia momentánea es tolerable, apunta a cache-aside. Un escenario que exige que el caché nunca sirva un dato desactualizado, sin importar el costo extra de cada escritura, apunta a write-through — a menudo combinado con cache-aside para cubrir también los nodos nuevos que arrancan vacíos.
Read replicas: el concepto que gobierna Task 3.3, profundidad completa en el Módulo 6
Una read replica es una copia de solo lectura de una base de datos, mantenida al día mediante replicación asíncrona desde la fuente. El propósito, según la documentación oficial de RDS, es distribuir el tráfico de lectura fuera de la instancia principal —que sigue siendo la única que acepta escrituras— para escalar más allá de la capacidad de una sola instancia en cargas con muchas más lecturas que escrituras.
La distinción de examen más citada, y la que este ecosistema nunca tuvo oportunidad de construir: una read replica no es lo mismo que la instancia en espera (standby) de una configuración Multi-AZ, que ya viste en el Módulo 3, lección 4. La documentación oficial lo confirma con precisión: la replicación hacia el standby de Multi-AZ es síncrona (para garantizar cero pérdida de datos en un failover) y el standby no puede servir tráfico de lectura — existe únicamente para tomar el lugar del primario si falla. Una read replica, en cambio, replica de forma asíncrona (existe una ventana de retraso, por pequeña que sea) y sí sirve tráfico de lectura real, todo el tiempo, mientras el primario sigue funcionando con normalidad.
READ REPLICA vs. STANDBY MULTI-AZ — LA CONFUSIÓN MÁS CITADA DE TASK 3.3
Read replica Standby Multi-AZ (Módulo 3, lección 4)
Replicación ....... Asíncrona Síncrona
Sirve lecturas? ... Sí, todo el tiempo No — solo toma el lugar del primario si falla
Propósito ......... Escalar LECTURAS Alta disponibilidad / failover
Puede estar en
otra Región? ...... Sí (cross-Region) No — Multi-AZ es dentro de la misma RegiónUna fuente de origen puede tener varias read replicas simultáneas —el límite exacto depende del motor de base de datos, cubierto con profundidad completa en el Módulo 6, lección 2, junto con RDS y Aurora en general— y también puede tener una read replica en una Región distinta a la fuente, útil tanto para reducir la latencia de lectura de usuarios lejanos como para tener, en un desastre regional, una base sobre la cual promover una nueva instancia principal.
La decisión de examen: un escenario que describe una base de datos relacional con mucho más tráfico de lectura que de escritura, y pide reducir la carga sobre la instancia principal sin cambiar de motor, apunta a agregar read replicas. Un escenario que describe la necesidad de sobrevivir la pérdida de la instancia principal sin intervención manual apunta a Multi-AZ — y un escenario que pide ambas cosas a la vez (leer más rápido y sobrevivir un fallo) puede, perfectamente, combinar las dos, porque no son mutuamente excluyentes.
DynamoDB DAX: la primera cobertura real de este ecosistema
aws-core-services-guide Módulo 7, lección 1, fue explícito: DAX quedó fuera del alcance de esa guía por diseño. DynamoDB Accelerator (DAX) es un caché compatible con la API de DynamoDB —tu aplicación usa, en esencia, el mismo cliente, con cambios funcionales mínimos— que reduce el tiempo de respuesta de lecturas eventualmente consistentes de milisegundos de un solo dígito a microsegundos, según la documentación oficial: un salto de un orden de magnitud completo.
DAX resuelve tres escenarios concretos, citados textualmente por AWS: aplicaciones que necesitan el tiempo de respuesta más rápido posible para lecturas (subastas en tiempo real, trading, juegos sociales); aplicaciones con una "hot key" —un ítem leído con mucha más frecuencia que el resto de la tabla, como el mismo escenario del producto en oferta de un día que ya viste en la sección de ElastiCache—; y aplicaciones de lectura intensiva pero sensibles al costo, donde desviar lecturas hacia DAX reduce cuánta capacidad de lectura de DynamoDB (RCU) necesitas comprar.
Lo que DAX explícitamente NO es, según la misma fuente oficial — y donde el examen más pone a prueba la lectura cuidadosa: no sirve para aplicaciones que exigen lecturas fuertemente consistentes (DAX solo acelera lecturas eventualmente consistentes); no ayuda a cargas intensivas en escritura (cada escritura se propaga a todos los nodos del clúster DAX, consumiendo más recursos cuantas más escrituras hay); y su rendimiento se degrada si la tasa de aciertos de caché (cache hit rate) cae por debajo del 90% recomendado — un patrón de lectura sin repetición real no se beneficia de DAX.
ELASTICACHE vs. DAX — LA DISTINCIÓN MÁS CITADA DE ESTA LECCIÓN
ElastiCache (Valkey/Memcached) DynamoDB DAX
─────────────────────────────────── ────────────────────────────────────
Caché de propósito general Caché ESPECÍFICO de DynamoDB
Delante de RDS/Aurora, o cualquier fuente Delante de DynamoDB, exclusivamente
Necesita lógica explícita de cache-aside/ API-compatible con DynamoDB — la aplicación
write-through en tu código apenas cambia
Latencia: milisegundos de un solo dígito Latencia: microsegundosLa decisión de examen: ElastiCache vs. DAX, resuelta en una pregunta. ¿La base de datos de origen es DynamoDB? Si sí, y el escenario describe lecturas repetidas que necesitan microsegundos, DAX es casi siempre la respuesta correcta —API-compatible, sin reescribir la lógica de caché a mano—. Si la base de datos de origen es relacional (RDS/Aurora) o el escenario no menciona DynamoDB en absoluto, ElastiCache es la respuesta, con la estrategia (cache-aside o write-through) determinada por la tolerancia a datos obsoletos que el escenario describe.
Errores comunes
Confundir read replica con el standby de Multi-AZ (el error más citado de esta lección, y un cruce directo con el Módulo 3). Qué pasa: alguien asume que una configuración Multi-AZ, por sí sola, ya distribuye el tráfico de lectura entre el primario y el standby. Cómo detectarlo: si tu diseño envía tráfico de lectura al standby de una configuración Multi-AZ. Cómo corregirlo: el standby de Multi-AZ nunca sirve tráfico —ni de lectura ni de escritura— mientras el primario esté sano; existe únicamente para el failover. Escalar lecturas exige read replicas explícitas, un recurso distinto y adicional al standby.
Elegir DAX para una carga con muchas escrituras y pocas lecturas repetidas (de aplicar la herramienta al problema equivocado). Qué pasa: alguien recomienda DAX para acelerar una tabla de DynamoDB con alto volumen de escrituras y lecturas mayormente únicas (sin repetición de la misma clave). Cómo detectarlo: si el escenario que estás resolviendo describe "muchas escrituras" o "lecturas variadas, sin ningún ítem accedido con más frecuencia que otro", y tu respuesta sigue siendo DAX. Cómo corregirlo: DAX está diseñado para lecturas repetidas de un subconjunto de claves (hot keys) con una tasa de aciertos alta — una carga intensiva en escritura, o con lecturas sin repetición real, no cumple el perfil que la documentación oficial describe como ideal, y podría, de hecho, degradar el rendimiento en vez de mejorarlo.
Elegir write-through por defecto "porque nunca tiene datos obsoletos", sin considerar el costo de cada escritura (de ignorar el trade-off explícito). Qué pasa: alguien asume que write-through es "estrictamente mejor" que cache-aside porque nunca sirve datos obsoletos. Cómo detectarlo: si tu justificación para write-through no menciona ningún costo ni penalización a cambio. Cómo corregirlo: write-through penaliza cada escritura con un viaje adicional al caché, y dificulta el manejo de nodos nuevos que arrancan vacíos — es la respuesta correcta cuando el escenario exige explícitamente cero tolerancia a datos obsoletos, no la opción "más segura" por defecto para cualquier escenario de caché.
❓ Pregunta de práctica — Dominio 3 (High-Performing)
Escenario: GameZone, una plataforma de juegos sociales en línea, guarda el estado de las partidas activas en una tabla DynamoDB. Durante un torneo popular, un pequeño número de partidas —las que están en la fase final, transmitidas en vivo— reciben decenas de miles de lecturas por segundo del mismo conjunto de ítems, mientras que el resto de las partidas activas del sistema reciben tráfico normal. El equipo necesita reducir la latencia de esas lecturas a microsegundos, sin reescribir la lógica de acceso a datos de la aplicación desde cero.
Pregunta: ¿Cuál solución es la más adecuada para este requisito?
A. Amazon ElastiCache for Memcached, con una estrategia de cache-aside implementada manualmente en el código de la aplicación. B. Amazon DynamoDB Accelerator (DAX), API-compatible con DynamoDB. C. Una read replica de la tabla DynamoDB, para distribuir las lecturas del torneo. D. Aumentar la capacidad aprovisionada (RCU) de la tabla DynamoDB al máximo disponible.
✅ Respuesta correcta: B
Por qué es correcta: el escenario describe, con precisión textual, el caso de uso central de DAX: un pequeño conjunto de ítems (las partidas en fase final) con lecturas extremadamente repetidas —exactamente el patrón de "hot keys" que la documentación oficial cita como caso ideal—, con el requisito explícito de microsegundos de latencia y sin reescribir la lógica de acceso a datos, porque DAX es API-compatible con DynamoDB y exige cambios funcionales mínimos en el cliente.
Por qué las demás fallan:
- A: ElastiCache es un caché de propósito general que exige implementar la lógica de cache-aside o write-through explícitamente en el código —justo lo que el escenario pide evitar—, y no ofrece la integración nativa API-compatible con DynamoDB que DAX sí ofrece.
- C: DynamoDB no tiene el concepto de "read replica" en el mismo sentido que RDS/Aurora — su mecanismo de distribución de lectura de baja latencia es, precisamente, DAX; "read replica" es terminología de bases de datos relacionales, no de DynamoDB.
- D: aumentar la capacidad aprovisionada (RCU) permite que la tabla acepte más lecturas por segundo sin throttling, pero no reduce la latencia de cada lectura individual a microsegundos — sigue siendo del orden de milisegundos de un solo dígito, el rendimiento nativo de DynamoDB sin un caché delante.
Resumen y siguiente paso
En esta lección cubriste, por primera vez en todo este ecosistema, las tres piezas de servicio nuevo de Task 3.3: ElastiCache (Valkey/Redis OSS vs. Memcached, y las estrategias cache-aside vs. write-through con su trade-off de lectura contra escritura), read replicas como el concepto que escala lecturas —distinto, con precisión, del standby de Multi-AZ—, y DynamoDB DAX como el caso de honestidad más citado del módulo: nombrado como frontera en aws-core-services-guide, enseñado de verdad aquí.
Antes de avanzar deberías poder explicar, en una frase, la diferencia entre una read replica y el standby de Multi-AZ, y decir de memoria cuándo DAX es la respuesta correcta frente a ElastiCache.
La lección 5 abre Task 3.4 — redes de alto rendimiento, con CloudFront y AWS Global Accelerator como las dos piezas de servicio nuevo más citadas de todo el examen en esta categoría.
Recursos
- AWS Certification — SAA-C03 Domain 3: Design High-Performing Architectures — fuente oficial de Task 3.3, citada en esta lección.
- Amazon ElastiCache — Caching strategies — fuente oficial de cache-aside, write-through y TTL, citada textualmente en esta lección.
- Amazon ElastiCache — Valkey vs. Memcached comparison — fuente oficial de la tabla comparativa de motores.
- Amazon RDS — Working with DB instance read replicas — fuente oficial de read replicas, replicación asíncrona y la distinción con Multi-AZ.
- Amazon DynamoDB — In-memory acceleration with DAX — fuente oficial de los casos de uso ideales y no ideales de DAX, citados textualmente en esta lección.
aws-core-services-guide, Módulo 7, lecciones 1 y 6 (NIEVA) — la frontera declarada de DAX y los modos de capacidad deShipmentsque esta lección da por resueltos.