1.1 O trade-off fundamental

Um cache guarda o resultado de uma operação cara (consulta, cálculo, chamada de API) perto de quem pede, para não repeti-la. Você troca frescor (o dado pode estar desatualizado) por latência (ordens de magnitude menor), carga (o backend recebe menos) e custo (menos CPU, menos chamadas pagas). A pergunta de projeto: quanto de desatualização este dado tolera? — de zero (saldo) a minutos (catálogo) a "para sempre até mudar" (um post publicado).

1.2 A hierarquia de caches

Cada camada resolve o pedido mais barato que a de baixo. O erro comum é pular direto para "colocar Redis" sem considerar CDN (para conteúdo público) ou L1 (para dados minúsculos e ultra-quentes).

1.3 As três métricas

• Hit ratio = hits ÷ (hits + misses). Abaixo de ~80% para um cache de leitura pesada, algo está errado (TTL curto demais, chave mal desenhada, working set maior que a memória).
• Latência (p50/p99) do cache e do caminho de miss. Um cache com p99 alto ou um miss que satura o banco anulam o ganho.
• Custo: memória do Redis + tráfego + a economia no backend. Um cache que guarda o que quase nunca é relido só custa.

2.1 As estruturas e para que servem

2.2 TTL e expiração

• EXPIRE k 300 / SET k v EX 300 / PEXPIRE (ms). TTL k consulta; PERSIST k remove.
• Expiração é preguiçosa + amostragem ativa: a chave some quando acessada após vencer, ou quando o ciclo de background a pega. Não conte com precisão de milissegundo.
• Escreveu sem TTL? A chave fica para sempre — a causa nº 1 de Redis lotando aos poucos. Num cache, todo SET tem TTL.

2.3 maxmemory e políticas de eviction

maxmemory 4gb
maxmemory-policy allkeys-lru

3.1 Os padrões

3.2 Cache-aside, o passo a passo (e onde ele erra)

// leitura
v = redis.get(k)
if v is None:
    v = db.query(...)                // MISS
    redis.set(k, serialize(v), ex=300)
return v

// escrita — INVALIDA, não atualiza o cache
db.update(...)
redis.delete(k)                       // próximo leitor repopula com o valor fresco do banco

• Invalidar (delete) > atualizar (set) na escrita: escrever o novo valor no cache na hora da escrita cria corrida (duas escritas concorrentes deixam o cache com o valor da mais lenta). Deletar e deixar o próximo leitor repopular do banco é mais seguro.
• TTL sempre, mesmo com invalidação explícita — é a rede de segurança contra invalidações perdidas (deploy, bug, mensagem não entregue).

3.3 Estratégias de invalidação

4.1 Cache stampede / dogpile / thundering herd

Sintoma: uma chave quente expira; centenas de requisições dão miss ao mesmo tempo e todas vão ao banco recomputar o mesmo valor, saturando-o.

• Lock de recomputação (single-flight / mutex): o primeiro a dar miss pega um lock (SET k:lock 1 NX PX 5000); os outros esperam um pouco e releem o cache. Só um recomputa.
• Early recomputation probabilístico (XFetch): recompute antes de expirar, com probabilidade que cresce à medida que o TTL se aproxima do fim — dilui a recomputação no tempo.
• Stale-while-revalidate: serve o valor vencido por alguns segundos enquanto um worker recomputa em background. Ninguém espera.

4.2 Cache avalanche

Sintoma: muitas chaves expiram ao mesmo tempo (populadas juntas num deploy, com TTL idêntico) — ou o Redis inteiro cai — e a carga desaba no banco de uma vez.

• Jitter no TTL: ex = base + random(0, base*0.2) — nunca TTL fixo para um lote.
• Warm-up pós-deploy: pré-carregar as chaves quentes antes de mandar tráfego.
• Degradação graciosa: se o Redis cai, a app aplica rate limit / circuit breaker no banco e serve resposta degradada — não repassa 100% da carga.

4.3 Cache penetration

Sintoma: requisições por chaves que não existem no banco (ids inválidos, ataque) sempre dão miss e sempre batem no banco — o cache não protege.

• Negative caching: cacheie o "não existe" com TTL curto (SET k "__nil__" EX 30).
• Bloom filter na frente: um filtro probabilístico responde "definitivamente não existe" sem tocar o banco (falsos positivos raros passam adiante; falsos negativos, nunca).
• Validar o formato da chave/id antes de consultar.

4.4 Hot key

Sintoma: uma única chave (o post viral, o produto da Black Friday) recebe tantas leituras que satura o nó do Redis que a hospeda (num Cluster, um slot num nó).

• L1 in-process na frente do Redis para as chaves quentíssimas (TTL de 1–5 s): a maioria das leituras nem chega ao Redis.
• Replicar a chave em N cópias (hotkey:0..9) e o cliente sortear qual ler — espalha a carga por mais slots/nós.
• Detecção: redis-cli --hotkeys, ou métricas por slot/nó.

4.5 Big key

Sintoma: uma chave gigante (um Hash com milhões de campos, uma List de centenas de MB) — operações sobre ela bloqueiam o Redis (single-thread), a replicação engasga, e a expulsão dela causa um stall.

• Quebrar em sub-chaves (hash:{user}:{shard}); nunca deixar uma coleção crescer sem limite (LTRIM, TTL, particionamento).
• Nunca HGETALL/SMEMBERS numa coleção enorme — use HSCAN/SSCAN com cursor.
• Detecção: redis-cli --bigkeys, MEMORY USAGE k.

5.1 Por que "atualizar os dois" não é atômico

Cache e banco são sistemas separados; não há transação entre eles. Qualquer sequência de "escreve no banco" + "mexe no cache" tem uma janela onde um crash, um timeout ou uma reordenação deixa os dois divergentes. O objetivo não é eliminar a divergência (impossível), é torná-la breve e auto-corrigível.

5.2 A corrida clássica da invalidação

// Thread A (leitura, deu miss)      Thread B (escrita)
A: lê do banco  → v_antigo
                                     B: escreve no banco → v_novo
                                     B: DEL cache[k]
A: SET cache[k] = v_antigo           // ← cache agora tem valor velho, sem TTL de socorro próximo

• Mitigação 1 — TTL curto: a janela de inconsistência fica limitada ao TTL. Simples e suficiente para a maioria dos dados.
• Mitigação 2 — delayed double delete: a escrita deleta a chave, atualiza o banco, e agenda um segundo DEL alguns segundos depois (pega o SET atrasado do leitor).
• Mitigação 3 — versão monotônica: o valor no cache carrega a versão do banco; um SET só sobrescreve se a versão for maior (via Lua/CAS). O SET atrasado do leitor tem versão menor e é rejeitado.

5.3 Invalidate vs update na escrita

Padrão de mercado: write-invalidate por default; write-update só quando o miss pós-escrita é caro e você adiciona controle de versão.

5.4 Invalidação por CDC avançado

Em vez de o código de escrita lembrar de invalidar todas as chaves derivadas, um consumidor de Change Data Capture (Debezium lendo o WAL/oplog) recebe cada mudança e invalida as chaves afetadas. Vantagens: desacopla (quem escreve não precisa conhecer o cache), cobre todas as fontes de escrita (incluindo migrações e jobs), e é uma trilha auditável. Custo: mais uma peça de infra e consistência eventual (o atraso do pipeline). Liga com o módulo 9 da apostila de NoSQL.

6.1 Rate limiting

// Token bucket atômico em Lua (evita corrida entre GET e SET)
// KEYS[1]=bucket  ARGV: taxa, capacidade, agora, custo
local b = redis.call('HMGET', KEYS[1], 'tokens', 'ts')
local tokens = tonumber(b[1]) or tonumber(ARGV[2])
local ts = tonumber(b[2]) or tonumber(ARGV[3])
tokens = math.min(tonumber(ARGV[2]), tokens + (ARGV[3]-ts)*ARGV[1])
if tokens < tonumber(ARGV[4]) then return 0 end
redis.call('HMSET', KEYS[1], 'tokens', tokens-ARGV[4], 'ts', ARGV[3])
redis.call('EXPIRE', KEYS[1], 3600)
return 1

• Fixed window (INCR + EXPIRE): simples, mas permite 2× o limite na virada da janela.
• Sliding window log (ZSet com score = timestamp, ZREMRANGEBYSCORE + ZCARD): preciso, custa memória por evento.
• Token bucket / leaky bucket: permite rajada controlada; o padrão para APIs. Faça atômico com Lua.
• Bibliotecas maduras existem (redis-cell como módulo, ou libs de linguagem) — não reinvente sem motivo.

6.2 Locks distribuídos com ressalvas

SET lock:recurso <token-aleatório> NX PX 30000     // adquire: só se não existe, com expiração
// libera com Lua: só apaga se o token for meu (senão apago o lock de outro)
if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) end

• Sempre com token único (para liberar só o seu) e TTL (para não travar para sempre se o dono morrer).
• Redlock (lock sobre N nós Redis independentes) existe para mais garantia, mas é controverso: Martin Kleppmann mostrou que ele não é seguro sob pausas de GC / relógios divergentes; Antirez respondeu. Consenso prático: para correção (nunca dois donos), use um sistema de consenso de verdade (ZooKeeper, etcd) ou fencing tokens; para eficiência (evitar trabalho duplicado, e tudo bem se raramente falhar), o lock simples do Redis basta.
• Fencing token: o lock devolve um número crescente; o recurso protegido rejeita operações com token menor que o último visto. É o que torna um lock realmente seguro.

6.3 Filas: Lists vs Streams

Redis não substitui Kafka/RabbitMQ para garantias fortes e volume altíssimo, mas Streams cobrem muito caso de fila sem trazer outra peça de infra.

6.4 Pub/Sub e Keyspace Notifications

• Pub/Sub clássico é fire-and-forget: quem não está inscrito no momento perde a mensagem. Bom para invalidação de cache L1 entre instâncias, sinais efêmeros. Para durável, use Streams.
• Keyspace notifications: o Redis pode publicar eventos quando chaves mudam/expiram (notify-keyspace-events) — útil para reagir a expiração (ex.: "sessão expirou → limpar recurso").

6.5 Outros usos consagrados

• Sessões distribuídas (Hash ou string serializada, TTL = duração da sessão).
• Leaderboards e rankings em tempo real (ZSet).
• Deduplicação / "processei este evento?" (Set ou string com TTL; ou HyperLogLog para contagem).
• Feature store online / cache de features de ML no caminho de inferência (Hash por entidade).

7.1 Por que o Redis é rápido (e onde isso morde)

• Tudo em memória + estruturas de dados otimizadas + protocolo simples (RESP).
• Single-thread para a execução de comandos: sem locks, sem troca de contexto, previsível. Consequência: um comando lento bloqueia todos (KEYS, SMEMBERS de coleção enorme, Lua pesada, FLUSHALL síncrono). Desde a 6.0 há I/O threads só para ler/escrever sockets — o processamento continua serial.
• Regra de ouro: comandos O(1) ou O(log n); nada de O(n) sobre coleções grandes no caminho quente.

7.2 Disponibilidade: réplica + Sentinel

• Replicação assíncrona: um primário, N réplicas (replicaof). Leituras podem ir a réplicas (aceitando lag). A replicação assíncrona significa que um failover pode perder as últimas escritas não replicadas.
• Redis Sentinel: processos que monitoram o primário, elegem um novo entre as réplicas em caso de falha e reconfiguram os clientes. É a alta disponibilidade para topologia não-clusterizada.
• WAIT numreplicas timeout força uma escrita a esperar confirmação de N réplicas — durabilidade sob demanda, com custo de latência.

7.3 Escala horizontal: Redis Cluster

• O keyspace é dividido em 16384 hash slots; slot = CRC16(key) mod 16384. Cada nó primário é dono de uma faixa de slots (e tem réplicas).
• O cliente é "cluster-aware": sabe qual nó tem qual slot e segue redirecionamentos (MOVED/ASK) durante rebalanceamento.
• Operações multi-chave (MGET, transações, Lua com várias chaves) só funcionam se todas as chaves caem no mesmo slot. Use hash tags: {user:42}:profile e {user:42}:cart têm o mesmo slot porque só o que está entre {} conta no hash.
• Rebalancear (adicionar/remover nó) move slots e as chaves deles — planeje janelas.

7.4 Persistência: RDB e AOF

Para cache puro, muitos rodam sem persistência (o dado é reconstruível do banco) — reduz latência e risco de fork pesado. Para Redis como store/fila, AOF everysec + RDB.

7.5 Memória e latência: o que monitorar

• INFO memory: used_memory vs maxmemory; mem_fragmentation_ratio (> 1,5 = fragmentação; jemalloc + activedefrag ajudam); evicted_keys.
• INFO stats: keyspace_hits/misses (hit ratio), instantaneous_ops_per_sec, expired_keys, rejected_connections.
• Slowlog (SLOWLOG GET) e Latency Monitor (LATENCY DOCTOR): achar comandos lentos e picos (fork do RDB, expiração em massa, swap).
• Nunca deixar o Redis usar swap — mata a latência. maxmemory com folga da RAM física.
• Clientes: CLIENT LIST, buffers de saída (um cliente lento com MONITOR ou pub/sub pode inchar a memória).

8.1 L1 (in-process) + L2 (Redis)

• L1: um cache de memória dentro da instância (Caffeine em Java, lru-cache em Node, functools.lru_cache/cachetools em Python). Latência de nanossegundos, zero rede. Escopo: uma instância. TTL curtíssimo (1–10 s).
• L2: Redis, compartilhado por todas as instâncias. Latência de sub-milissegundo, com rede.
• Leitura: L1 → (miss) L2 → (miss) banco, populando de volta as camadas. A maioria esmagadora das leituras para as chaves quentes morre no L1 — é a defesa contra hot key (módulo 4).

8.2 O problema da coerência entre L1s

Cada instância tem seu próprio L1. Quando um dado muda, invalidar o L2 (Redis) não invalida os N L1s. Estratégias:

• TTL curtíssimo no L1 (1–5 s): aceita-se a inconsistência por segundos. Simples e, na prática, suficiente para a maioria dos casos.
• Pub/Sub de invalidação: ao mudar um dado, publica invalidate user:42 num canal Redis; toda instância assina e limpa a chave do seu L1. Propagação em milissegundos.
• Client-side caching do Redis (RESP3 tracking) 6.0+: o próprio Redis notifica os clientes quando uma chave que eles leram muda — L1 coerente "de fábrica", com modo broadcasting ou por opt-in de chave.

8.3 Cache HTTP e na borda

• Purga da CDN por evento (mudança de preço → purge da URL do produto) + stale-while-revalidate cobre a janela.
• Edge compute (Cloudflare Workers, Vercel Edge, Fastly Compute) pode montar respostas personalizadas na borda com um KV de baixa latência — cache "quase na origem do usuário".
• ESI / fragmentos: cachear partes da página com TTLs diferentes (o cabeçalho por 1 dia, o bloco de recomendação por 5 min).

9.1 Cache de LLM tema em alta

Redis serve os três: string para o exato, Redis com busca vetorial (RediSearch/Redis Query Engine) para o semântico. Ganho típico: latência e custo de tokens caem muito em fluxos com repetição (FAQ, classificação, prompts de template). Ver a apostila de RAG e a de LLMOps.

9.2 Redis como banco primário — quando e riscos

• Quando dá certo: dados que são naturalmente chave-valor / estruturas do Redis, cabem na memória (com folga e crescimento previsto), e cuja perda de segundos em um failover é aceitável ou mitigada. Ex.: estado de jogo em tempo real, sessões, filas, feature store.
• Configuração: maxmemory-policy noeviction (não pode expulsar dado autoritativo!), AOF everysec + RDB, réplicas + Sentinel/Cluster, backups testados.
• Riscos: replicação assíncrona = janela de perda no failover; custo de RAM vs disco; um FLUSHALL ou bug apaga tudo em memória. Para dado que não pode se perder, ou use Redis Enterprise/serviços gerenciados com garantias mais fortes, ou mantenha uma fonte de verdade durável e trate o Redis como camada acelerada.

9.3 O panorama de alternativas

9.4 O ângulo de custo

• Cache é RAM, e RAM é cara: custo do Redis vs economia no banco/nas APIs pagas. Meça as duas pontas.
• TTL curto demais = hit ratio baixo = você paga o Redis e a carga no backend. TTL longo demais = memória inflada com lixo frio.
• Comprima valores grandes (gzip/zstd) se a CPU compensar a RAM; use Hash em vez de N strings; OBJECT ENCODING para ver se a estrutura está na codificação compacta.
• Serverless: cada instância abre pool — em picos, isso multiplica conexões; use um proxy/pooler ou os clientes HTTP (Upstash e afins) desenhados para isso.
• Tiered storage (RAM + SSD) em ofertas gerenciadas pode baratear datasets grandes com cauda fria.

10.1 Onde cai

10.2 Roadmap (4 semanas)

• Sem. 1 — módulos 1–3: adicionar cache-aside com Redis a uma API real, com TTL + jitter e invalidação por delete; medir hit ratio e latência antes/depois.
• Sem. 2 — módulo 4: provocar e mitigar cada um dos 5 problemas num teste de carga (k6): stampede (lock/SWR), avalanche (jitter), penetration (negative cache/bloom), hot key (L1), big key (SCAN).
• Sem. 3 — módulo 6: implementar rate limiter (token bucket em Lua), lock distribuído com token + TTL, e uma fila com Streams + consumer group.
• Sem. 4 — módulos 7–8: subir Redis Cluster (3+3) local, lidar com CROSSSLOT/hash tags, e montar L1+L2 com invalidação por pub/sub; brincar com Cache-Control/ETag/SWR numa CDN.

10.3 Banco de perguntas (com a resposta que aprova)

10.4 Projetos de portfólio

1. Laboratório dos 5 problemas: uma API + Redis + k6, com um branch por problema (stampede, avalanche, penetration, hot key, big key) mostrando o sintoma no gráfico de carga e a correção. README com os números antes/depois. Extremamente convincente.
2. Toolkit de Redis: rate limiter (token bucket em Lua), lock com fencing token, fila com Streams + DLQ, tudo com testes de concorrência.
3. Cache de LLM: exato + semântico (com limiar calibrado e um conjunto de avaliação medindo falso-reuso), sobre um assistente simples, comparando latência e custo de tokens com e sem cache.

10.5 Fontes

• Documentação oficial do Redis (a página de cada comando traz a complexidade — decore os O(n)); o livro Redis in Action; o post de Martin Kleppmann "How to do distributed locking" e a resposta do Antirez.
• Designing Data-Intensive Applications para consistência e sistemas distribuídos.
• MDN sobre Cache-Control; a RFC 5861 (stale-while-revalidate/stale-if-error).
• Apostilas irmãs: NoSQL, Modelagem de Dados NoSQL, Observabilidade & SRE, Arquitetura & System Design.