Caching: ElastiCache, DAX e Padrões
Cache é o pattern mais antigo e mais efetivo para reduzir latência e custo de banco. Mas implementar mal resulta em dados stale, invalidação confusa e bugs sutis. O SAA cobra: escolha de produto (Redis × Memcached × DAX × CloudFront), escolha de padrão (cache-aside × write-through × write-behind) e interpretação de métricas.
ElastiCache: Redis vs Memcached
| Dimensão | Redis | Memcached |
|---|---|---|
| Estruturas | Strings, lists, sets, sorted sets, hashes, streams, hyperloglog, geo | Apenas key-value string |
| Multi-thread | Single-threaded (1 core por node) | Multi-threaded (escala vertical melhor) |
| Persistência | RDB snapshots + AOF log | Nenhuma (puramente in-memory) |
| Replicação | Read replicas + cluster mode | Sharding client-side, sem replicação |
| High Availability | Multi-AZ com automatic failover | Não nativo |
| Pub/Sub | Sim | Não |
| Transactions | Sim (MULTI/EXEC) | Não |
| Encryption in-transit / at-rest | Sim (TLS + KMS) | In-transit sim, at-rest não |
| Caso de uso | Session store, leaderboards, filas, geo, pub/sub | Cache puro simples, multi-thread, sem persistência |
Redis: Cluster Mode Disabled vs Enabled
| Feature | Cluster Disabled | Cluster Enabled |
|---|---|---|
| Shards | 1 shard | Até 500 shards |
| Dataset máximo | Limitado ao tamanho de 1 node (~600GB) | Horizontal scaling — petabytes |
| Client | Conexão simples | Precisa de cluster-aware client |
| Primary failover | Auto com Multi-AZ | Auto por shard |
| Backup | Snapshot completo | Snapshot por shard |
| Caso | Sessions, cache de API pequeno-médio | Datasets grandes, high throughput distribuído |
DAX — cache nativo do DynamoDB
DAX é um cache in-memory write-through compatível com a API do DynamoDB. A aplicação troca o endpoint e ganha latência μs (microssegundos). Roda em cluster de nodes na VPC.
App (DynamoDB SDK)
│
▼
┌─────────┐
│ DAX │──── Item Cache (GetItem / BatchGetItem)
│ cluster │──── Query Cache (Query / Scan)
└────┬────┘
│ miss
▼
DynamoDB ← write-through: DAX propaga PUT/UPDATE/DELETECloudFront — cache de borda para HTTP/S
CloudFront não é “o mesmo que ElastiCache mas HTTP”. É CDN global com POPs em ~450 cidades. Cache é controlado por cache policy (TTL + keys baseadas em query string/headers/cookies) e origin request policy (o que forward para a origem).
Padrões de cache — decor e aplique
| Padrão | Como funciona | Prós | Contras |
|---|---|---|---|
| Cache-Aside (Lazy) | App verifica cache; miss → busca DB → popula cache | Simples, cacheia apenas o usado | Primeiro hit é miss; stale data possível |
| Read-Through | Cache é provider: app lê do cache, ele busca do DB automaticamente | Código limpo | Depende de integração suportada |
| Write-Through | App escreve cache, cache escreve DB sincronamente | Consistência forte | Escrita mais lenta; cache cresce com dados nunca lidos |
| Write-Behind | App escreve cache; cache escreve DB async em batch | Escritas muito rápidas | Risco de perda se cache falhar antes do flush |
| Refresh-Ahead | Expira itens quentes pró-ativamente antes do TTL | Hit rate alto | Complexidade de previsão |
# Cache-aside típico (Python + redis + RDS)
def get_user(user_id):
key = f"user:{user_id}"
cached = redis.get(key)
if cached:
return json.loads(cached)
user = db.query("SELECT * FROM users WHERE id = %s", user_id)
redis.setex(key, 300, json.dumps(user)) # TTL 5min
return user
def update_user(user_id, data):
db.execute("UPDATE users SET ... WHERE id = %s", user_id)
redis.delete(f"user:{user_id}") # invalidação explícitaEscolha arquitetural — quando cada um ganha
📋 Sessão de usuário de e-commerce compartilhada entre múltiplas instâncias EC2
Session store requer acesso rápido de múltiplos hosts. Redis é tradicional. DynamoDB on-demand é alternativa serverless mais moderna.
Alt: Sticky sessions no ALB — funciona mas amarra usuário a 1 host e falha em failover.
📋 API pública com endpoints /produtos e /categorias acessados 10.000 req/s, dados mudam 1x/dia
CDN absorve 99% dos requests na edge, origem quase nunca é tocada. Invalidação na atualização diária.
Alt: API Gateway com caching — funciona mas fica em 1 região.
📋 Leaderboard de jogo — top 100 jogadores, atualizado a cada partida, consulta por tempo real
ZADD + ZREVRANGE resolve em uma chamada. Nem DynamoDB nem DAX oferecem sorted sets nativos.
Métricas críticas do ElastiCache (CloudWatch)
Q&A estilo exame
❓ Quando usar DAX e quando usar ElastiCache na frente do DynamoDB?
❓ Como escolher entre cache-aside e write-through?
❓ Redis Multi-AZ com auto-failover — RTO típico?
❓ Aplicação começou a retornar dados antigos após deploy. Como diagnosticar?
/* (última medida). Em ElastiCache:FLUSHALL derruba tudo — use com cautela.Quiz rápido
3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito