Cache Inteligente com Redis: Estrategias Que Fazem Sua Aplicacao Voar em 2026

Redis e o banco de dados in-memory mais popular do mundo. Usado como cache, message broker, session store e muito mais, Redis pode reduzir a latencia da sua aplicacao de centenas de milissegundos para menos de 1ms. Este guia mostra estrategias avancadas de cache com Redis na pratica.

Por que cache importa

Sem cache: cada requisicao faz query no banco de dados (10-100ms), processa a resposta (1-10ms), retorna o resultado. Com muitas requisicoes simultaneas, o banco se torna gargalo.

Com cache Redis: primeira requisicao faz a query e armazena resultado no Redis. Requisicoes seguintes buscam no Redis (menos de 1ms). Resultado: latencia 100x menor e banco de dados com 90% menos carga.

Estrategias de cache

Cache-Aside (Lazy Loading)

O padrao mais usado. A aplicacao e responsavel por gerenciar o cache:

import redis
import json

r = redis.Redis(host=”localhost”, port=6379, db=0)

def buscar_produto(produto_id):
# 1. Tentar buscar no cache
cache_key = f”produto:{produto_id}”
cached = r.get(cache_key)

if cached:
return json.loads(cached) # Cache hit!

# 2. Cache miss: buscar no banco
produto = db.query(“SELECT * FROM produtos WHERE id = %s”, [produto_id])

if produto:
# 3. Salvar no cache com TTL de 5 minutos
r.setex(cache_key, 300, json.dumps(produto))

return produto

Vantagens: so armazena dados que sao realmente acessados, falha do cache nao impede o funcionamento (degrada gracefully). Desvantagens: primeira requisicao sempre e lenta (cache cold), dados podem ficar desatualizados ate o TTL expirar.

Write-Through

Toda escrita vai para o cache E para o banco simultaneamente:

def atualizar_produto(produto_id, dados):
# Atualizar no banco
db.execute(“UPDATE produtos SET … WHERE id = %s”, [produto_id])

# Atualizar no cache
cache_key = f”produto:{produto_id}”
r.setex(cache_key, 300, json.dumps(dados))

O cache esta sempre atualizado. Mas adiciona latencia nas escritas (duas operacoes) e pode armazenar dados que nunca sao lidos.

Write-Behind (Write-Back)

Escritas vao apenas para o cache e sao persistidas no banco de forma assincrona. Menor latencia de escrita, mas risco de perda de dados se o Redis cair antes de persistir.

Patterns avancados

Cache Stampede Prevention

Quando o cache expira para um item popular, centenas de requisicoes simultaneas vao todas para o banco. Solucao com lock distribuido:

def buscar_produto_safe(produto_id):
cache_key = f”produto:{produto_id}”
lock_key = f”lock:produto:{produto_id}”

cached = r.get(cache_key)
if cached:
return json.loads(cached)

# Tentar adquirir lock (SET NX com TTL)
if r.set(lock_key, “1”, nx=True, ex=10):
try:
# Eu ganhei o lock: buscar no banco e popular cache
produto = db.query(“SELECT * FROM produtos WHERE id = %s”, [produto_id])
r.setex(cache_key, 300, json.dumps(produto))
return produto
finally:
r.delete(lock_key)
else:
# Outro processo esta populando: esperar brevemente e tentar cache novamente
import time
time.sleep(0.1)
cached = r.get(cache_key)
return json.loads(cached) if cached else buscar_produto_safe(produto_id)

Cache Warming

Pre-popular o cache na inicializacao com dados mais acessados:

def warm_cache():
# Top 1000 produtos mais acessados
produtos = db.query(“SELECT * FROM produtos ORDER BY acessos DESC LIMIT 1000”)

pipe = r.pipeline()
for produto in produtos:
pipe.setex(f”produto:{produto[“id”]}”, 3600, json.dumps(produto))
pipe.execute() # Envia todos de uma vez (pipeline para performance)

Multi-Layer Cache

Cache L1 (in-memory local, ex: dict Python com TTL curto — 10s) para dados ultra-frequentes. Cache L2 (Redis, TTL maior — 5min) para dados frequentes. Banco de dados para dados nao cacheados.

Redis alem do cache

Session store: armazenar sessoes de usuario (mais rapido que banco). Rate limiting: implementar limite de requisicoes por usuario com INCR e EXPIRE. Leaderboard: rankings em tempo real com Sorted Sets. Pub/Sub: notificacoes em tempo real entre servicos. Queue: fila de jobs simples com LPUSH/BRPOP.

Metricas de cache

Cache hit rate: porcentagem de requisicoes atendidas pelo cache. Alvo: acima de 90%. Cache miss rate: requisicoes que precisaram ir ao banco. Se alto, revise TTLs e estrategia. Memory usage: monitore o uso de memoria do Redis para evitar OOM. Eviction rate: frequencia com que itens sao removidos por falta de memoria.

Redis na nuvem

Para producao: Amazon ElastiCache (Redis gerenciado na AWS), Google Cloud Memorystore, Azure Cache for Redis, Redis Cloud (do criador do Redis). Todos oferecem alta disponibilidade, replicacao automatica e clustering.