Load Balancer e Redis no seu sistema: tutorial pra pedir pra IA e validar

Load Balancer e Redis são as 2 mudanças que separam MVP de produto sério. Não são luxo. São o momento em que você para de rezar pra o servidor não cair e começa a projetar pra ele não cair.

Este tutorial é o que eu ensino pra founder que começou no vibecoding e chegou no ponto de "o site travou de novo com 200 usuários".

O que é Load Balancer (LB)

Imagina que seu site é uma padaria. Se você tem 1 balconista e chega uma fila de 20 pessoas, cria gargalo. Load Balancer é você ter 5 balconistas, com um segurança na porta distribuindo:

• Cliente A → balconista 1
• Cliente B → balconista 2
• Cliente C → balconista 3

Se balconista 2 falta ou fica doente, o segurança sabe e para de mandar cliente pra ele. Loja continua funcionando.

Em software:

• Sem LB: 1 servidor recebe tudo. Se cair, site cai.
• Com LB: 3 servidores recebem tráfego. Se um cair, os outros 2 seguem. LB detecta e retira o quebrado da roleta.

Quando ativar Load Balancer

Regra prática:

• Tráfego < 1000 requests concorrentes: não precisa. Vercel/Cloudflare já fazem isso.
• Tráfego 1000-10.000 requests concorrentes: ative se tem servidor próprio Node/Python.
• SLA de 99.9%+ pra cliente: obrigatório.
• Vários países acessando: LB geográfico melhora latência.

Se você tá em Vercel, Cloudflare, Netlify: você já tem LB por default. Só se importe se saiu desses.

O que é Redis

Redis é uma memória rápida em RAM. Bem rápida. Latência de 1-2ms contra 20-100ms de banco tradicional.

Use pra 3 coisas:

1. Cache: guardar resposta de query pesada. Se você pergunta "quantos produtos tem?" e o banco leva 800ms pra responder, você guarda a resposta no Redis por 60 segundos. Próximas 100 pessoas que perguntam recebem em 2ms.

2. Sessão de login: guardar quem tá logado. Toda request precisa verificar isso. Se guardar no banco, cada request paga 20ms. No Redis, 1ms.

3. Rate limit: contar "quantas vezes o usuário X fez essa ação nos últimos 60 segundos". Rate limit no banco é dor. No Redis é 2 linhas.

Quando ativar Redis

• Rota lenta que muita gente acessa: ativa pra essa rota específica.
• Muitos logins simultâneos: ativa pra sessão.
• Endpoint público sendo abusado: ativa rate limit.

Se você ainda não tem esses problemas, não instala. Complexidade sem dor é dívida técnica adiantada.

Como pedir pra IA fazer isso: 4 prompts P.R.O.M.P.T.E.R. prontos

O erro comum é pedir "coloca Redis no meu app". IA vai chutar formato, colar chave no código, esquecer TTL. Prompts abaixo são o contrato certo.

Prompt 1: Adicionar Redis (cache de query)

Papel: você é engenheiro sênior de back-end, especialista em Next.js
       e Upstash Redis. Se algo ficar ambíguo, pergunta antes de gerar.

Regras:
- Usar Upstash Redis via cliente @upstash/redis (não instalar redis package puro).
- Chave da conexão SEMPRE em variável de ambiente
  (UPSTASH_REDIS_REST_URL e UPSTASH_REDIS_REST_TOKEN).
- NUNCA colar chave no código.
- Todo cache tem TTL. Default 60 segundos.
- Nome da chave do cache tem prefixo (ex: "produto:count") pra debug fácil.

Objetivo: adicionar cache Redis na rota /api/produtos/count
que hoje leva 800ms.

Modelo: função pura src/lib/cache.ts com getOrSet(chave, ttl, fn)
+ modificação da rota.

Parâmetros:
- TTL 60 segundos.
- Se Redis falhar, cai pra fetch direto no banco (não quebra o app).

Teste: incluir 3 casos:
1. cache miss (pega do banco, salva no cache)
2. cache hit (retorna do cache)
3. Redis offline (fallback pro banco)

Retorno: só código, sem comentário fora dele.

Prompt 2: Session em Redis (login)

Papel: você é engenheiro sênior de segurança e Redis.

Regras:
- Sessão fica em Redis com TTL de 7 dias.
- ID de sessão é UUID v4 gerado no servidor
  (nunca deixar cliente escolher).
- Chave no formato "session:{uuid}".
- Payload da sessão contém APENAS: userId, createdAt, lastSeen.
- NÃO guardar senha, e-mail, token de terceiros.
- Logout apaga a chave.

Objetivo: substituir sessão em cookie stateful atual por sessão Redis.

Modelo: src/lib/session.ts com create, get, refresh, destroy.

Parâmetros:
- TTL 604800 segundos (7 dias).
- Refresh a cada acesso: atualiza lastSeen mas NÃO reseta TTL.

Teste: 4 casos:
1. Criar sessão nova.
2. Ler sessão válida.
3. Ler sessão expirada (retorna null).
4. Destruir sessão.

Retorno: código completo do session.ts + como usar
em middleware Next.js.

Prompt 3: Rate limit no Redis

Papel: você é engenheiro sênior anti-abuso.

Regras:
- Rate limit por IP + rota (não só IP).
- Janela deslizante de 60 segundos.
- Limite: 100 requests por janela.
- Se estourar, retornar HTTP 429 com header Retry-After.
- Chave no formato "ratelimit:{ip}:{rota}".
- Usar comando INCR + EXPIRE pra ser atômico.

Objetivo: proteger rota /api/lead-email de abuso.

Modelo: middleware src/lib/rate-limit.ts com função rateLimit(req)
que retorna { ok, retryAfter }.

Parâmetros:
- Limite 100 req por 60 segundos.
- IP vem de x-forwarded-for (Vercel).

Teste: 3 casos:
1. Primeira request passa.
2. 101ª request retorna 429.
3. Após 60 segundos, contador reseta.

Retorno: só código.

Prompt 4: Load Balancer via Cloudflare

Aqui muda: LB não é código, é configuração. O prompt pra IA é orientação, não geração de código.

Papel: você é engenheiro DevOps especialista em Cloudflare.

Regras:
- Configurar Load Balancer Cloudflare (não AWS ELB).
- 3 origins: Vercel principal, Vercel backup, Render como fallback.
- Health check a cada 30 segundos no endpoint /api/health.
- Se origin retornar não-200 em 3 checks seguidos, retira da roleta.
- Voltar automaticamente quando /api/health voltar a retornar 200.
- Distribuição: round robin com peso 3-2-1.

Objetivo: guia passo a passo pra configurar Load Balancer
Cloudflare pra domínio [seu-dominio.com.br].

Modelo: lista numerada de passos com screenshots ou nomes exatos
dos campos no dashboard Cloudflare.

Teste: incluir o comando curl pra validar cada origin manualmente
+ como simular queda de um origin.

Retorno: markdown com passos + endpoint /api/health que o Next.js
precisa expor (código dele).

Como validar se tá funcionando

Não confia no "acho que sim". Testa.

Validar Redis (3 comandos)

1. Ping:

redis-cli -h [seu-redis-host] PING
# Retorna: PONG

Se retornar PONG, conexão OK.

2. Monitor em tempo real:

redis-cli -h [seu-redis-host] MONITOR

Deixa rodando. Faz uma request no seu app. Deve aparecer SET e GET em tempo real. Se não aparece, o app não tá chamando Redis.

3. Latência caindo (o teste que importa):

Abre Chrome → F12 → Network. Roda a rota 1x (cold cache). Anota tempo. Roda 2x seguidas (warm cache). Compara.

• Antes de Redis: 800ms, 800ms, 800ms.
• Depois de Redis: 800ms (primeira, cold), 15ms, 15ms.

Se não caiu, Redis não tá ativado ou o TTL tá zerado.

Validar Load Balancer

1. Ver headers de resposta:

curl -I https://seu-dominio.com.br
# Procura header: cf-ray ou x-vercel-id
# Se aparecer, LB tá roteando.

2. Simular queda de origin:

Desliga uma das 3 instâncias. Roda curl 20 vezes.

Se todas responderam com 200, LB detectou e desviou. Se algumas deram 502, o health check ainda não removeu a instância morta. Aguarda 90 segundos e tenta de novo.

3. Ver distribuição:

for i in {1..30}; do
  curl -s https://seu-dominio.com.br/api/health | grep instance;
done

Se apareceu instance:1, instance:2, instance:3 misturados, LB tá distribuindo mesmo. Se veio tudo instance:1, algo tá errado.

Custo aproximado (07/07/2026)

Redis via Upstash (recomendado pra começar):

• Free tier: 10.000 comandos/dia + 256 MB. Suficiente pra MVP.
• Pago: US$ 0,20 por 100.000 comandos. R$ 1,03 por 100k.
• App médio (10.000 req/dia com cache): ~R$ 30/mês.

Load Balancer Cloudflare:

• Free tier: LB básico incluso.
• Plano Pro: US$ 20/mês (R$ 103) + US$ 5 por health check ativo.
• Vale se você tá em Cloudflare Pro por outros motivos (WAF, CDN).

AWS ALB (só se você tá em AWS):

• US$ 22/mês fixo + US$ 8 por LCU (load capacity unit).
• Complexo. Não recomendo pra começar.

Vale o ponto

"Mas isso tudo não é overengineering pra MVP?"

Vale o ponto. Não faça antes de precisar. Se seu MVP tem 50 usuários por dia e uma rota rápida, você não precisa de Redis. Não precisa de Load Balancer.

Você precisa quando:

• Rota fica >500ms consistentemente.
• Ver 500 error no log com tráfego médio.
• Cliente reclama de lentidão em horário de pico.
• SLA de 99.9%+ virou requisito de contrato.

Sinal de que tá na hora: você já mediu, você já sabe que a dor existe. Não é sensação, é dado.

Conclusão

Load Balancer é sobre não cair. Redis é sobre não ficar lento. Os dois juntos transformam MVP em produto sério.

A IA sabe fazer isso, mas erra em detalhes críticos (chave vazada, TTL zerado, cache stale). Prompts P.R.O.M.P.T.E.R. deste post te dão o contrato certo.

Depois de ativar, VALIDA. Nenhuma dessas mudanças é "confia que funcionou". Roda os 3 comandos.

Se travou algo, me manda no e-mail. Respondo direto.

A decisão é sua.