Aula 19 - Rate Limiting, Throttling e Proteção contra Ataques 🛡️

📑 1. Fundamentos Teóricos & Análise Técnica

Serviços expostos à internet pública estão sujeitos a ataques de negação de serviço (DoS/DDoS), credential stuffing, raspagem agressiva de dados (scraping) e degradação de infraestrutura por clientes mal configurados. Para garantir a disponibilidade contínua do sistema (High Availability), mecanismos de controle de vazão de tráfego são imperativos.

Os dois conceitos operam em camadas distintas: 1. Rate Limiting: Política que define o número máximo de requisições que uma entidade identificada (por IP, API Key ou User ID) pode realizar em uma janela temporal (ex: 100 requisições por minuto). 2. Throttling: Técnica de estrangulamento que desacelera progressivamente o processamento das requisições excedentes ou enfileira chamadas antes de rejeitá-las abruptamente.

Os algoritmos industriais mais eficientes são: - Token Bucket: Balde virtual que recebe tokens em taxa constante. Cada requisição consome um token; se o balde esvaziar, o cliente recebe HTTP 429 Too Many Requests. Suporta rajadas curtas (bursts). - Sliding Window Log / Counter: Mantém o registro temporal exato no Redis com estruturas ZSET, calculando a soma móvel das requisições na janela deslizante com precisão milimétrica.

📐 Arquitetura Conceitual & Diagrama de Fluxo

flowchart TD
    Req["Requisição do Cliente"] --> CheckRedis["Consulta Janela no Redis (Sliding Window)"]
    CheckRedis --> LimitCheck{"Requisições na Janela < Limite?"}
    LimitCheck -->|Sim: Permitido| RegisterReq["Registra Timestamp no ZSET"]
    RegisterReq --> Forward["Encaminha para o Controller do Backend"]
    LimitCheck -->|Não: Excedido| Block["Retorna HTTP 429 Too Many Requests"]
    Block --> Headers["Headers: Retry-After, X-RateLimit-Reset"]
    style Req fill:#e1f5fe,stroke:#01579b
    style CheckRedis fill:#fff3e0,stroke:#e65100
    style Forward fill:#e8f5e9,stroke:#2e7d32
    style Block fill:#ffebee,stroke:#c62828

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Armazenamento Atômico em Redis: Execução de scripts Lua para checar e incrementar contadores em uma única operação atômica de rede. - Headers Informativos RFC 6585: Envio dos cabeçalhos X-RateLimit-Limit, X-RateLimit-Remaining e Retry-After. - Rate Limiting Multinível: Políticas globais por IP combinadas com limites estritos por usuário autenticado. - Degradação Graciosa (Graceful Degradation): Circuit Breakers que cortam integrações lentas antes que causem travamento geral do pool de threads.

🛠️ 2. Implementação Prática em Proteção de APIs, Redis e Resiliência

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// sliding_window_rate_limiter.lua (Script Lua Atômico para Redis)
-- Script Lua executado atomicamente no Redis
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local limit = tonumber(ARGV[3])

local clearBefore = now - window

-- 1. Remove registros fora da janela deslizante atual
redis.call('ZREMRANGEBYSCORE', key, '-inf', clearBefore)

-- 2. Conta quantas requisições restam na janela
local currentRequests = redis.call('ZCARD', key)

if currentRequests < limit then
  -- 3. Adiciona a requisição atual com score igual ao timestamp
  redis.call('ZADD', key, now, now)
  redis.call('EXPIRE', key, math.ceil(window / 1000))
  return 1 -- Permitido!
else
  return 0 -- Bloqueado (Limite Excedido)!
end

💡 Análise Passo a Passo do Código

1. Atomicidade Absoluta: Scripts Lua executam sem interrupção no Redis, eliminando condições de corrida (race conditions) em acessos concorrentes.
2. Remoção Automática: ZREMRANGEBYSCORE descarta logs antigos instantaneamente antes de calcular o total.
3. Precisão Temporal: A janela deslizante evita a vulnerabilidade clássica de borda das janelas fixas (Fixed Window Spikes).

🎯 3. Próximos Passos & Sequência Didática