SAA-C03
Deep Dive
La caché es fundamental para arquitecturas de alto rendimiento. El examen evalúa cuándo usar cada tipo: ElastiCache para aplicaciones, DAX para DynamoDB, CloudFront para contenido web. También evalúa patrones de caché como lazy loading y write-through.
Contenido
La caché reduce latencia almacenando datos frecuentemente accedidos en memoria — órdenes de magnitud más rápida que disco o base de datos. También reduce la carga en la base de datos, permitiendo servir más tráfico con la misma infraestructura.
~10 ms
Base de datos (HDD)
~1 ms
Base de datos (SSD)
~0.1 ms
In-memory (Redis)
| Característica | Redis | Memcached |
|---|---|---|
| Persistencia | Sí (RDB + AOF snapshots) | No (solo memoria) |
| Replicación / Multi-AZ | Sí — réplicas de lectura + failover | No |
| Clustering / Sharding | Cluster Mode (sharding horizontal) | Nativo multi-thread por nodo |
| Estructuras de datos | Strings, hashes, sets, sorted sets, lists, HyperLogLog | Solo strings simples |
| Pub/Sub | Sí | No |
| Backup / Restore | Sí | No |
| Threads | Single-thread por core (Cluster Mode = multi-nodo) | Multi-thread nativo |
| Caso de uso | Sesiones, leaderboards, pub/sub, cache con HA | Cache simple de objetos, multi-thread |
Elige Redis cuando...
Elige Memcached cuando...
Regla práctica para el examen
Si la pregunta menciona cualquiera de estas palabras → Redis: "sesiones", "persistencia", "Multi-AZ", "replicación", "pub/sub", "sorted sets", "leaderboards". Si dice "caché simple", "objetos", "multi-thread", "sin requisitos de HA" → Memcached.
DAX (DynamoDB Accelerator) es un cluster de caché in-memory totalmente administrado, diseñado específicamente para DynamoDB. Reduce la latencia de lecturas de milisegundos a microsegundos.
Cómo funciona
Tu aplicación usa el SDK de DAX en vez del SDK de DynamoDB
DAX primero busca en su caché in-memory
Cache hit: respuesta en microsegundos
Cache miss: DAX consulta DynamoDB y cachea el resultado
La aplicación no cambia — mismo API de DynamoDB
DAX vs ElastiCache para DynamoDB
DAX
Caché específico de DynamoDB. Transparente para la app. Entiende el modelo de datos de DynamoDB.
ElastiCache (Redis)
Caché de propósito general. Requiere lógica en la app para gestionar caché. Puede cachear resultados de múltiples fuentes.
Señal DAX en el examen
"Latencia de microsegundos para DynamoDB" o "miles de lecturas por segundo en DynamoDB" → DAX. DAX no ayuda con operaciones de escritura.
CloudFront no es solo un CDN para contenido estático — también cachea respuestas dinámicas de APIs y puede reducir dramáticamente la latencia para usuarios globales.
Cache TTL
Cuánto tiempo CloudFront cachea un objeto. Configurado por Cache-Control o Expires headers del origen, o por CloudFront Cache Policy.
Cache Key
Qué elementos del request forman la clave de caché. Por defecto solo el URL. Puede incluir headers, cookies o query strings.
Origin Shield
Capa adicional de caché entre los Edge Locations y el origen. Reduce requests al origen hasta un 60%.
Invalidaciones
Fuerza a CloudFront a descartar objetos cacheados. Útil tras deploy de nuevas versiones de código/assets.
Lazy Loading (Cache-Aside)
Solo cacheas cuando hay un cache miss. La app primero busca en caché; si no está, consulta la BD y lo escribe en caché.
Ventajas
+Solo cachea datos realmente usados
+La caché puede fallar sin romper la app
Desventajas
-Primer acceso lento (cache miss)
-Datos pueden quedar stale
Write-Through
Cada escritura a la BD también actualiza la caché. Los datos en caché siempre están frescos.
Ventajas
+Sin datos stale
+Cache siempre caliente para datos escritos
Desventajas
-Escrituras más lentas (2 operaciones)
-Puede cachear datos que nunca se leen
TTL — Time To Live
Todos los patrones de caché deben incluir TTL para evitar datos stale indefinidamente. El TTL ideal depende de la frecuencia de actualización de los datos: sesiones de usuario (30 min), resultados de búsqueda (5 min), perfil de usuario (1 hora), catálogo de productos (24 horas).
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación web tiene una base de datos RDS con consultas lentas de lectura que están afectando la experiencia del usuario. Los datos del catálogo de productos cambian raramente (1-2 veces al día). ¿Qué patrón de caché y servicio son más adecuados?