Rate Limiting em Produção: Proteja Sua API e Aplicações Web

1. O que é Rate Limiting

rate limiting em produção. Rate limiting é um mecanismo para controlar a quantidade de requisições que um usuário ou serviço pode fazer em determinado período.
Objetivos principais:

• Evitar abusos e ataques, como DDoS ou brute force.
• Proteger recursos críticos do servidor.
• Garantir qualidade de serviço para todos os usuários.

Exemplo:

• Uma API permite 100 requisições por minuto por IP.
• Se um usuário enviar 150 requisições, 50 serão rejeitadas com HTTP 429 Too Many Requests.

Implementar rate limiting é uma das estratégias mais eficientes para proteger aplicações contra picos inesperados de tráfego ou abuso de APIs. Essa abordagem faz parte de uma mentalidade operacional mais madura, focada em prevenir incidentes antes que eles ocorram. No guia sobre como sair do modo de apagar incêndio na administração de servidores, mostramos como adotar práticas mais proativas na gestão de infraestrutura.

2. Estratégias comuns de Rate Limiting

2.1 Token Bucket (mais flexível)

• Cada usuário tem um “balde” de tokens.
• Cada requisição consome 1 token.
• Tokens são regenerados a uma taxa fixa (ex.: 10 tokens por segundo).
• Permite explosões curtas, desde que haja tokens disponíveis.

2.2 Leaky Bucket (mais constante)

• Requisições entram em um “balde com furos”.
• Saem a uma taxa constante.
• Garante fluxo regular, útil para limitar tráfego em tempo real.

2.3 Fixed Window (simples)

• Conta requisições em intervalos fixos (ex.: minuto ou hora).
• Fácil de implementar, mas pode permitir picos no final da janela.

2.4 Sliding Window (mais precisa)

• Semelhante ao Fixed Window, mas janelas se sobrepõem.
• Evita picos e distribui melhor as requisições.

3. Implementação prática

3.1 Rate limiting em APIs (exemplo com Nginx)

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

    server {
        location /api/ {
            limit_req zone=mylimit burst=10 nodelay;
            proxy_pass http://backend;
        }
    }
}

• rate=5r/s → máximo 5 requisições por segundo por IP.
• burst=10 → permite até 10 requisições adicionais em um pico.
• nodelay → responde imediatamente com 429 se estourar o limite.

3.2 Rate limiting em aplicações (exemplo Node.js / Express)

import rateLimit from 'express-rate-limit';

const apiLimiter = rateLimit({
  windowMs: 60 * 1000, // 1 minuto
  max: 100, // máximo 100 requisições por IP
  standardHeaders: true,
  legacyHeaders: false,
  message: 'Você excedeu o limite de requisições.'
});

app.use('/api/', apiLimiter);

• Fácil de adicionar a qualquer rota de API.
• Pode ser customizado por usuário, rota ou método HTTP.

3.3 Rate limiting distribuído (Redis / Memcached)

• Para vários servidores, usar memória local não funciona.
• Estratégia comum: armazenar contadores em Redis.
• Permite sincronizar limites de requisições por usuário em múltiplas instâncias.

Exemplo conceitual:

Chave Redis: rate:{user_id}
Valor: contador de requisições
Expiração: 1 minuto

• Incrementa contador a cada requisição.
• Se contador > limite → retorna 429.

4. Boas práticas

1. Retorne 429 com Retry-After → informa ao cliente quando tentar novamente.
2. Diferencie limites por usuário vs IP → APIs autenticadas podem ter limites maiores.
3. Proteja rotas críticas primeiro → login, reset de senha, checkout.
4. Evite bloquear serviços internos → limite apenas tráfego externo.
5. Monitoramento e alertas → identificar abusos ou falhas de configuração.

5. Exemplos reais de uso

Muitos incidentes em produção são causados por sobrecarga inesperada de requisições ou ausência de mecanismos de proteção na aplicação. Implementar controles como rate limiting é uma forma eficiente de evitar incidentes recorrentes e sair do modelo reativo de operação de servidores.

Guia Completo de Rate Limiting em Produção

1. Conceito e Estratégia

Objetivo: proteger APIs e aplicações web de abusos, DDoS e picos inesperados, sem prejudicar usuários legítimos.

Estratégia recomendada em produção:

1. Rate limiting por IP (para tráfego público).
2. Rate limiting por usuário/conta (para APIs autenticadas).
3. Limite diferenciado por endpoint (login, checkout, reset de senha recebem limites mais restritos).
4. Rate limiting distribuído (para múltiplos servidores, usando Redis ou Memcached).

2. Nginx: Rate Limiting na Prática

2.1 Configuração básica (single server)

http {
    # Define zona de limite por IP
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

    server {
        listen 80;
        server_name suaapi.com;

        location /api/ {
            limit_req zone=mylimit burst=20 nodelay;
            proxy_pass http://127.0.0.1:3000;
        }
    }
}

• rate=10r/s → 10 requisições por segundo por IP
• burst=20 → permite até 20 requisições extras em picos
• nodelay → rejeita imediatamente se ultrapassar burst
• Retorna HTTP 429 para requisições acima do limite

2.2 Rate Limiting com chaves personalizadas (usuário/rota)

limit_req_zone $http_api_key zone=userlimit:10m rate=5r/s;

location /api/critical/ {
    limit_req zone=userlimit burst=5 nodelay;
    proxy_pass http://127.0.0.1:3000;
}

• Aqui o limite é por API Key (ou token no header) em vez de IP.
• Permite limites diferenciados para cada cliente.

3. Node.js / Express: Rate Limiting na Aplicação

3.1 Rate limiting básico por IP

import rateLimit from 'express-rate-limit';

const apiLimiter = rateLimit({
  windowMs: 1 * 60 * 1000, // 1 minuto
  max: 100, // 100 requisições por IP
  message: 'Você excedeu o limite de requisições. Tente novamente mais tarde.',
  standardHeaders: true,
  legacyHeaders: false
});

app.use('/api/', apiLimiter);

3.2 Rate limiting por usuário autenticado (Redis distribuído)

import rateLimit from 'express-rate-limit';
import RedisStore from 'rate-limit-redis';
import Redis from 'ioredis';

const redisClient = new Redis({ host: '127.0.0.1', port: 6379 });

const userLimiter = rateLimit({
  store: new RedisStore({ sendCommand: (...args) => redisClient.call(...args) }),
  windowMs: 60 * 1000, // 1 minuto
  max: 200, // 200 requisições por usuário
  keyGenerator: (req) => req.user.id, // limite por ID de usuário
  message: 'Limite de requisições por usuário excedido.'
});

app.use('/api/private/', userLimiter);

Vantagem: funciona em multi-server e mantém contagem centralizada no Redis.

4. Monitoramento e Logs

1. Nginx logs:

log_format ratelimit '$remote_addr - $status [$time_local] "$request" '
                      'limit_req_status=$limit_req_status';

access_log /var/log/nginx/access.log ratelimit;

• $limit_req_status indica se a requisição foi limitada (ex: 429).

2. Node.js logs:

app.use((req, res, next) => {
    res.on('finish', () => {
        if(res.statusCode === 429) {
            console.warn(`Rate limit hit: ${req.ip} on ${req.originalUrl}`);
        }
    });
    next();
});

3. Alertas:

• Configurar alertas se >5% das requisições estiverem retornando 429 → possível ataque ou mal uso.
• Ferramentas: Prometheus + Grafana, ou logs enviados para ELK/Graylog.

5. Boas Práticas

1. Endpoints críticos primeiro: login, checkout, reset de senha.
2. Use Retry-After: informa aos clientes quando tentar de novo.
3. Diferencie limites: usuários autenticados podem ter mais requisições.
4. Burst control: permita pequenos picos sem bloquear tráfego legítimo.
5. Teste com carga: verifique que o serviço se mantém estável sob limite aplicado.

6. Exemplo de Checklist para Produção

• Nginx configurado com limit_req
• Express com rate limiting básico
• Redis para contagem distribuída
• Logging de requisições limitadas
• Alertas para picos de 429
• Endpoints críticos com limites mais restritos
• Documentação para API clientes (ex: 429 + Retry-After)

FAQ

Veja Mais:

Sair do Modo Apagar Incêndio em Servidores
Storage em Cloud: NVMe Local vs Compartilhado vs Object Storage
Reduzindo Ruído em Monitoramento de Servidores
SSD NVMe Lento: 9 Causas Comuns e Como Resolver