Resumo

Imagine um e-commerce em que toda visita à página de um produto dispara uma query no banco de dados relacional para buscar preço, estoque e descrição. Em um dia normal isso funciona. Numa liquidação, com 50x mais acessos batendo nos mesmos produtos em destaque, o banco satura — não porque os dados mudaram, mas porque a mesma pergunta está sendo respondida milhares de vezes por segundo.

ElastiCache resolve esse tipo de problema: é um serviço gerenciado de cache em memória, que guarda dados frequentemente acessados perto da aplicação (em RAM, não em disco), reduzindo drasticamente a latência e tirando carga repetitiva do banco de dados.

• ElastiCache: serviço gerenciado que provisiona, opera e escala engines de cache em memória — sem você administrar servidor, patch ou failover manualmente.
• Redis: engine rica em funcionalidades — estruturas de dados avançadas, persistência, replicação, transações, pub/sub. É a escolha padrão quando você não tem certeza de qual usar.
• Memcached: engine mais simples — multi-threaded, sem persistência, sem replicação nativa. Ideal para cache puro e descartável, distribuído horizontalmente por sharding simples.
• Cache-aside (lazy loading): o padrão de uso mais comum — a aplicação consulta o cache primeiro; se não encontrar (cache miss), busca no banco e grava o resultado no cache para a próxima vez.

---

1. Por que usar cache — o problema, na prática

Bancos de dados relacionais (RDS, Aurora) são ótimos para consistência e consultas complexas, mas ler do disco (ou mesmo de um buffer pool) sob alta concorrência tem um custo: latência de alguns milissegundos por query, multiplicada por milhares de requisições repetidas para os mesmos dados.

Um cache em memória resolve isso guardando o resultado de uma consulta cara, disponível em microssegundos numa segunda leitura. Os ganhos típicos:

• Latência: leituras em memória são ordens de magnitude mais rápidas que leituras em disco.
• Redução de carga no banco: cada leitura respondida pelo cache é uma query a menos no RDS/Aurora — ajuda a adiar (ou evitar) upgrades de instância só por volume de leitura repetitiva.
• Escalabilidade de leitura barata: é mais barato escalar nós de cache do que escalar réplicas de um banco relacional para o mesmo volume de leituras repetidas.

O ElastiCache entrega isso como serviço gerenciado: a AWS cuida de provisionamento de nós, patching, monitoramento, failover (quando configurado) e backups — você foca em decidir o que cachear e por quanto tempo.

---

2. Redis vs Memcached — a decisão central

Essa comparação é, de longe, o ponto mais cobrado da prova sobre ElastiCache.

Regra prática para a prova: se a questão menciona qualquer uma dessas palavras — persistência, replicação, Multi-AZ, failover automático, transações, pub/sub, estruturas de dados complexas, leaderboard/ranking — a resposta é Redis. Se a questão descreve cache simples, descartável, que precisa de multi-threading para aproveitar múltiplos núcleos de CPU num único nó, e sharding simples e massivo sem se importar com perda de dados em um restart, a resposta é Memcached.

---

3. Estratégias de caching

Como o cache é preenchido e mantido atualizado importa tanto quanto qual engine usar.

3.1 Lazy loading (cache-aside)

O padrão mais usado. Fluxo:

1. Aplicação pede o dado ao cache.
2. Cache hit: dado está lá, retorna direto — rápido.
3. Cache miss: dado não está no cache. Aplicação busca no banco de dados, retorna ao usuário e grava o resultado no cache para a próxima leitura.

Vantagens: só armazena dados que realmente são solicitados (eficiente em memória); se o nó de cache cair, a aplicação continua funcionando (mais lenta, buscando direto no banco) até o cache voltar.

Desvantagem: a primeira leitura de qualquer dado sempre é um cache miss (mais lenta) — e dados no cache podem ficar desatualizados (stale) se o banco mudar sem que o cache seja invalidado.

3.2 Write-through

A cada escrita no banco, a aplicação também escreve no cache, mantendo os dois sempre sincronizados.

Vantagem: o cache nunca fica desatualizado — dados sempre consistentes com o banco.

Desvantagem: toda escrita fica mais lenta (grava em dois lugares); dados que nunca são lidos ocupam espaço no cache desnecessariamente; se o nó de cache estiver fora, a estratégia mais simples de write-through falha a escrita ou exige lógica extra de contingência.

3.3 TTL (Time To Live)

Complementa qualquer uma das estratégias acima: define um tempo de expiração para cada chave. Depois desse tempo, o dado é removido automaticamente do cache, forçando uma releitura (e atualização) do banco na próxima consulta.

💡 Regra prática para a prova: lazy loading é o padrão default recomendado (resiliente a falha do cache, eficiente em memória) — combine com TTL para evitar dados eternamente desatualizados. Write-through entra quando a consistência entre cache e banco é crítica e você pode aceitar escrita mais lenta.

---

4. Arquitetura do Redis no ElastiCache

4.1 Cluster Mode Disabled

Um único shard (grupo primário + até 5 réplicas de leitura), replicando de forma assíncrona a partir de um nó primário. Todas as escritas vão para o primário; leituras podem ser distribuídas entre as réplicas para escalar throughput de leitura.

• Escala leitura adicionando réplicas.
• Não escala escrita horizontalmente — o primário é o único ponto de escrita, limitado pela memória de um único nó.

4.2 Cluster Mode Enabled

Os dados são particionados (sharded) entre até 500 shards, cada shard com seu próprio primário e réplicas opcionais. As chaves são distribuídas entre shards por hash slots.

• Escala escrita e leitura horizontalmente, porque cada shard tem seu próprio nó primário.
• É a opção correta quando o volume de dados ou de escrita excede a capacidade de um único nó primário.

4.3 Multi-AZ e failover automático

Com Multi-AZ habilitado, se o nó primário de um shard falhar, o ElastiCache promove automaticamente uma réplica a primário — sem intervenção manual — minimizando downtime. Sem Multi-AZ, uma falha no primário exige intervenção manual para restaurar a capacidade de escrita.

4.4 Global Datastore

Permite replicação entre regiões: um cluster Redis primário replica de forma assíncrona para clusters secundários em outras regiões AWS, útil para aplicações globais que precisam de leitura de baixa latência perto do usuário, ou para disaster recovery entre regiões.

---

5. Arquitetura do Memcached no ElastiCache

Memcached não tem conceito de primário/réplica — todos os nós de um cluster são independentes e equivalentes. A distribuição dos dados entre eles é feita pelo cliente (via hashing consistente na biblioteca cliente), não pelo servidor.

• Auto Discovery: recurso do ElastiCache que permite ao cliente descobrir automaticamente todos os nós do cluster sem precisar de configuração manual de endpoints a cada mudança.
• Adicionar ou remover nós redistribui as chaves entre os nós disponíveis (o cliente recalcula o hashing) — não há cópia automática de dados entre nós, então um scale-in ou falha de nó perde os dados daquele nó (sem impacto de correção, porque é cache, mas com impacto em performance até o cache "esquentar" de novo).
• Sem persistência: um restart de nó (ou falha) apaga os dados daquele nó — a aplicação simplesmente vai ter mais cache misses até repopular.

---

6. Persistência no Redis

Só o Redis oferece isso — é um dos motivos centrais para escolhê-lo quando dados de cache não podem simplesmente desaparecer numa falha.

• RDB (Redis Database) snapshots: fotografias periódicas de todo o dataset, salvas em S3 de forma gerenciada. Permitem restaurar o cluster a partir de um ponto no tempo, mas dados escritos entre o último snapshot e uma falha são perdidos.
• AOF (Append Only File): registra cada operação de escrita à medida que acontece, permitindo uma recuperação mais granular. Tem mais overhead de I/O do que RDB.
• Backup and restore: snapshots RDB também podem ser usados para criar um novo cluster a partir de um backup — por exemplo, para popular um ambiente de testes com uma cópia dos dados de produção.

⚠️ Mesmo com persistência habilitada no Redis, o ElastiCache continua sendo cache — não é indicado como fonte única de verdade para dados que precisam de garantias fortes de durabilidade como um banco transacional (RDS/Aurora/DynamoDB). Persistência aqui existe para acelerar recuperação após falha, não para substituir o banco primário.

---

7. Eviction policies — o que fazer quando o cache enche

Quando a memória do nó atinge o limite (maxmemory), o Redis precisa decidir o que remover para abrir espaço para novas chaves. Algumas políticas comuns (maxmemory-policy):

• allkeys-lru: remove a chave menos recentemente usada entre todas as chaves — boa política default para cache genérico.
• volatile-lru: remove a menos recentemente usada, mas só entre chaves que têm TTL configurado — chaves sem expiração nunca são removidas por essa política.
• noeviction: não remove nada; novas escritas passam a falhar com erro quando a memória enche — útil quando o Redis está sendo usado para algo além de cache puro (ex: fila), onde perder dados silenciosamente seria pior que falhar a escrita.

---

8. Segurança

• Encryption at rest: criptografa os dados armazenados em disco (relevante para snapshots RDB e AOF) usando KMS.
• Encryption in transit: criptografa a comunicação entre a aplicação e o cluster (TLS) — tem impacto de performance, mas protege dados sensíveis trafegando pela rede.
• Redis AUTH: exige uma senha (token) para qualquer cliente se conectar ao cluster Redis — camada extra além do controle de rede.
• IAM authentication (Redis): alternativa mais moderna ao AUTH token, permitindo autenticação e autorização usando políticas IAM em vez de gerenciar uma senha compartilhada.
• VPC e Security Groups: por padrão, clusters ElastiCache rodam dentro de uma VPC, isolados de acesso público — o acesso é controlado por security groups, exatamente como em uma instância EC2 ou RDS.
• Memcached não possui AUTH nativo equivalente ao Redis — o isolamento de rede via VPC/security group é a principal camada de proteção.

---

9. Casos de uso comuns

• Cache de resultados de banco de dados: o caso clássico — cachear resultados de queries caras e repetitivas (lazy loading + TTL).
• Session store: guardar sessões de usuário fora da própria instância da aplicação, permitindo que qualquer instância atrás de um load balancer atenda qualquer usuário sem "session stickiness" — essencial em arquiteturas stateless com Auto Scaling.
• Leaderboards e ranking em tempo real: usando Sorted Sets do Redis, que mantêm elementos ordenados automaticamente por um score (ex: pontuação de um jogo), com operações eficientes de "top N" ou "posição de um jogador".
• Pub/Sub: Redis permite publicar mensagens em canais e ter múltiplos assinantes reagindo em tempo real — usado para notificações e comunicação leve entre componentes.
• Rate limiting / contadores: operações atômicas de incremento (INCR) no Redis são úteis para controlar taxas de requisição por usuário/API key.

---

10. Boas práticas

• Use Redis como escolha default quando houver dúvida — a menos que a simplicidade e o multi-threading do Memcached sejam especificamente necessários.
• Combine lazy loading com TTL para a maioria dos casos — é a estratégia mais resiliente e eficiente em memória.
• Habilite Multi-AZ com failover automático em Redis sempre que o cache for crítico para a disponibilidade da aplicação (ex: session store).
• Use Cluster Mode Enabled quando o volume de dados ou de escrita ultrapassar a capacidade de um único nó primário.
• Nunca trate o ElastiCache como fonte única de verdade para dados que exigem durabilidade forte — ele é um acelerador, não um substituto do banco primário.
• Monitore métricas do CloudWatch como CacheHitRate, Evictions e CurrConnections para saber se o tamanho do cluster está adequado ao padrão de acesso real.

---

11. Exercícios e revisão

1. Explique por que uma aplicação de leaderboard de jogo deveria usar Redis em vez de Memcached, citando a estrutura de dados específica envolvida.
2. Compare o comportamento de lazy loading e write-through diante de uma falha temporária do cluster de cache.
3. Descreva um cenário em que noeviction seria mais apropriado que allkeys-lru.
4. Explique a diferença entre Cluster Mode Disabled e Cluster Mode Enabled em termos de escalabilidade de escrita.

---

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Laboratório Prático

Objetivo: criar um cluster ElastiCache Redis com Multi-AZ habilitado e validar a estratégia de lazy loading a partir de uma aplicação simples.

Pré-requisitos: uma VPC com pelo menos 2 subnets privadas em AZs diferentes; uma instância EC2 (ou Cloud9) na mesma VPC para testar a conexão.

Tempo estimado: 25 minutos

Possíveis custos: o cluster ElastiCache fica ativo durante o laboratório — lembre-se de fazer a limpeza ao final para não gerar cobrança contínua. Custo aproximado de poucos centavos se limpo em até 1 hora.

Passos:

1. No console do ElastiCache, crie um subnet group apontando para as subnets privadas da sua VPC.
2. Crie um cluster Redis com um nó primário cache.t3.micro, 1 réplica de leitura, e Multi-AZ com failover automático habilitado.
3. Configure um security group que permita tráfego na porta 6379 apenas a partir do security group da sua instância EC2 de teste.
4. Na instância EC2, instale um cliente Redis (ex: redis-cli ou pip install redis para Python) e conecte-se usando o endpoint primário do cluster.
5. Escreva um script simples simulando lazy loading: consulte uma chave; se não existir (cache miss), simule uma "busca no banco" (ex: time.sleep(1) retornando um valor fixo) e grave o resultado no cache com SETEX chave 60 valor (TTL de 60 segundos).
6. Execute o script duas vezes seguidas e compare o tempo de resposta — a segunda execução deve ser praticamente instantânea (cache hit).
7. No console, force um failover manual do nó primário (opção "Test Failover") e observe uma réplica sendo promovida automaticamente, sem downtime perceptível para leituras nas réplicas restantes.

Resultado esperado: a segunda leitura da mesma chave retorna quase instantaneamente (cache hit), comprovando o ganho de latência do cache; e o failover de teste demonstra a troca automática de primário sem intervenção manual.

Limpeza dos recursos: delete o cluster Redis, depois o subnet group do ElastiCache, para evitar dependências travadas.

---

Referências:

• ElastiCache overview: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html
• Redis vs Memcached: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/SelectEngine.html
• Caching strategies: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html
• Redis replication: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.html
• Redis backup and restore: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html
• Global Datastore: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html