AWS SAA-C03/06 - Bancos de Dados2 min
ElastiCache
Responda com suas palavras antes de ler o resto da nota.
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off (custo, latência, operação)?
- Que sinal no enunciado aponta pra isso?
- Com o que isso é confundido na prova?
Conceito
Cache in-memory gerenciado. Tira carga do banco e derruba latência de leitura de milissegundos para sub-milissegundo.
| Redis | Memcached | |
|---|---|---|
| Persistência | Sim (snapshot + AOF) | Não |
| Réplica / Multi-AZ | Sim, com failover automático | Não |
| Estruturas de dados | Lista, set, sorted set, hash, pub/sub, stream | Só chave-valor |
| Multi-thread | Não (single-thread por nó) | Sim |
| Sharding | Cluster mode | Sharding nativo |
| Backup | Sim | Não |
| Transações / Lua | Sim | Não |
Regra que resolve a maioria das questões: precisa sobreviver, replicar ou usar estrutura de dados → Redis. Cache puro, descartável e multi-threaded → Memcached.
Padrões de cache
| Padrão | Como funciona | Risco |
|---|---|---|
| Lazy loading / cache-aside | Só popula no miss | Primeiro acesso é lento; dado pode ficar velho |
| Write-through | Escreve no cache e no banco juntos | Cache sempre atualizado; escrita mais lenta, dado nunca lido ocupa espaço |
| TTL | Expira depois de N segundos | Simples; escolher o valor é o problema |
Casos de uso clássicos
Sessão de usuário (deixa a aplicação stateless), leaderboard (sorted set do Redis), cache de query cara, rate limiting, e resultado de API externa.
MemoryDB for Redis
Compatível com Redis, mas com durabilidade de banco de dados (log transacional multi-AZ). Use quando o dado em memória é a fonte da verdade, não um cache.
Trade-offs
Cache resolve leitura repetida e introduz o problema da invalidação: dado desatualizado servindo usuário. Lazy loading só carrega o que se pede (economiza memória, aceita miss lento); write-through mantém tudo fresco e enche o cache de coisa que ninguém lê. A combinação usual é write-through com TTL.
ElastiCache não fala com o banco sozinho — a aplicação precisa ser modificada para consultar o cache primeiro. Isso é diferente de DAX, que é transparente e só funciona com DynamoDB.
Sinais de prova
- "Reduzir carga de leitura repetida no RDS" → ElastiCache
- "Guardar sessão para deixar as instâncias stateless" → Redis (ou DynamoDB)
- "Leaderboard de jogo em tempo real" → Redis sorted set
- "Cache simples, barato, escalar horizontal, multi-thread" → Memcached
- "Cache que sobrevive a reinício e faz failover" → Redis
- "Dado em memória como fonte da verdade" → MemoryDB
- "Cache transparente para DynamoDB" → DAX, não ElastiCache
Relacionado
Parte de 06 - MOC Bancos de Dados · Documentação AWS