title: "Rate Limiting Algorithms: Token Bucket, Leaky Bucket e Sliding Window" slug: "rate-limiting-algorithms" excerpt: "APIs sem rate limiting quebram sob carga. Descubra algoritmos Token Bucket, Leaky Bucket e Sliding Window para throttling, burst control e proteção contra DDoS." tags: ["rate-limiting", "algorithms", "api", "scalability", "ddos"] date: "2026-01-21" published: true reading_time: "95 min"

English summary: Token bucket, leaky bucket, sliding window algorithms, quando usar e métricas.

Rate Limiting Algorithms: Token Bucket, Leaky Bucket e Sliding Window

Sua API recebe 1000 requests/segundo de um único cliente. Seus servidores derretem. Rate limiting protege contra abuso controlando quantas requests um cliente pode fazer em um período.

Algoritmos Principais

1. Fixed Window Counter

Conta requests em janelas de tempo fixas:

Window 1: 0-60s  → 100 requests (OK)
Window 2: 60-120s → 150 requests (BLOCK se limit = 100)

class FixedWindowRateLimiter {
  private windows: Map<string, { count: number; startTime: number }> = new Map();

  constructor(
    private maxRequests: number,
    private windowMs: number  // ex: 60000 = 1 minuto
  ) {}

  isAllowed(clientId: string): boolean {
    const now = Date.now();
    const window = this.windows.get(clientId);

    if (!window || now - window.startTime >= this.windowMs) {
      // Nova janela
      this.windows.set(clientId, { count: 1, startTime: now });
      return true;
    }

    if (window.count < this.maxRequests) {
      window.count++;
      return true;
    }

    return false;  // Rate limit exceeded
  }
}

// Uso
const limiter = new FixedWindowRateLimiter(100, 60000);  // 100 req/min

console.log(limiter.isAllowed('user1')); // true
// ... 99 more requests
console.log(limiter.isAllowed('user1')); // true (100th)
console.log(limiter.isAllowed('user1')); // false (exceeded)

Problema: Edge case - 200 requests em 2 segundos:

58s   → 100 requests (OK, window 1)
61s   → 100 requests (OK, window 2 resetou)
Total: 200 requests em 3 segundos!

2. Sliding Window Log

Armazena timestamp de cada request, calcula quantos nos últimos N segundos:

class SlidingWindowLog {
  private logs: Map<string, number[]> = new Map();

  constructor(
    private maxRequests: number,
    private windowMs: number
  ) {}

  isAllowed(clientId: string): boolean {
    const now = Date.now();
    const log = this.logs.get(clientId) || [];

    // Remove timestamps antigos (fora da janela)
    const validLog = log.filter(timestamp => now - timestamp < this.windowMs);

    if (validLog.length < this.maxRequests) {
      validLog.push(now);
      this.logs.set(clientId, validLog);
      return true;
    }

    return false;
  }
}

Vantagem: Preciso, sem edge cases

Desvantagem: Consome memória (armazena todos timestamps)

3. Sliding Window Counter (Híbrido)

Combina Fixed Window + Sliding Window:

class SlidingWindowCounter {
  private currentWindow: Map<string, number> = new Map();
  private previousWindow: Map<string, number> = new Map();
  private windowStart: number = Date.now();

  constructor(
    private maxRequests: number,
    private windowMs: number
  ) {}

  isAllowed(clientId: string): boolean {
    const now = Date.now();

    // Rotaciona janelas se necessário
    if (now - this.windowStart >= this.windowMs) {
      this.previousWindow = new Map(this.currentWindow);
      this.currentWindow.clear();
      this.windowStart = now;
    }

    const currentCount = this.currentWindow.get(clientId) || 0;
    const previousCount = this.previousWindow.get(clientId) || 0;

    // Peso baseado em quanto da janela anterior ainda conta
    const percentOfPrevious = Math.max(0, this.windowMs - (now - this.windowStart)) / this.windowMs;
    const estimatedCount = currentCount + (previousCount * percentOfPrevious);

    if (estimatedCount < this.maxRequests) {
      this.currentWindow.set(clientId, currentCount + 1);
      return true;
    }

    return false;
  }
}

4. Token Bucket

Balde com tokens. Cada request consome 1 token. Tokens são reabastecidos constantemente:

class TokenBucket {
  private buckets: Map<string, { tokens: number; lastRefill: number }> = new Map();

  constructor(
    private maxTokens: number,      // Capacidade do balde
    private refillRate: number      // Tokens/segundo
  ) {}

  isAllowed(clientId: string, cost: number = 1): boolean {
    const now = Date.now();
    let bucket = this.buckets.get(clientId);

    if (!bucket) {
      bucket = { tokens: this.maxTokens, lastRefill: now };
      this.buckets.set(clientId, bucket);
    }

    // Reabastecer tokens baseado no tempo passado
    const timePassed = (now - bucket.lastRefill) / 1000;  // segundos
    const tokensToAdd = timePassed * this.refillRate;
    bucket.tokens = Math.min(this.maxTokens, bucket.tokens + tokensToAdd);
    bucket.lastRefill = now;

    if (bucket.tokens >= cost) {
      bucket.tokens -= cost;
      return true;
    }

    return false;
  }
}

// Uso
const limiter = new TokenBucket(100, 10);  // 100 tokens, refill 10/s

console.log(limiter.isAllowed('user1', 1));  // true (-1 token)
console.log(limiter.isAllowed('user1', 50)); // true (-50 tokens)
console.log(limiter.isAllowed('user1', 60)); // false (só 49 tokens restantes)

// Após 5 segundos: +50 tokens (10/s * 5s)
setTimeout(() => {
  console.log(limiter.isAllowed('user1', 60)); // true
}, 5000);

Vantagem: Permite bursts (usar todos tokens de uma vez)

5. Leaky Bucket

Fila (queue). Requests entram na fila, saem em taxa constante:

class LeakyBucket {
  private queues: Map<string, number[]> = new Map();

  constructor(
    private maxQueueSize: number,
    private leakRateMs: number  // Taxa de vazamento (ms entre processar requests)
  ) {}

  async process(clientId: string, request: () => Promise<void>): Promise<boolean> {
    const queue = this.queues.get(clientId) || [];

    if (queue.length >= this.maxQueueSize) {
      return false;  // Queue cheia
    }

    queue.push(Date.now());
    this.queues.set(clientId, queue);

    // Processar na taxa de vazamento
    await new Promise(resolve => setTimeout(resolve, this.leakRateMs * queue.length));
    await request();

    queue.shift();
    return true;
  }
}

// Uso
const limiter = new LeakyBucket(10, 100);  // Max 10 na fila, vaza 1 a cada 100ms

await limiter.process('user1', async () => {
  console.log('Processing request');
});

Vantagem: Taxa de saída constante (smoothing)

Desvantagem: Adiciona latência (requests ficam em fila)

Implementação com Redis

Para sistemas distribuídos, use Redis com Lua scripts (atômico):

-- Token Bucket em Redis
local key = KEYS[1]
local max_tokens = tonumber(ARGV[1])
local refill_rate = tonumber(ARGV[2])
local cost = tonumber(ARGV[3])
local now = tonumber(ARGV[4])

local bucket = redis.call('HMGET', key, 'tokens', 'last_refill')
local tokens = tonumber(bucket[1]) or max_tokens
local last_refill = tonumber(bucket[2]) or now

-- Refill
local time_passed = (now - last_refill) / 1000
local tokens_to_add = time_passed * refill_rate
tokens = math.min(max_tokens, tokens + tokens_to_add)

if tokens >= cost then
  tokens = tokens - cost
  redis.call('HMSET', key, 'tokens', tokens, 'last_refill', now)
  redis.call('EXPIRE', key, 3600)
  return 1  -- Allowed
else
  return 0  -- Blocked
end

// Node.js
import { createClient } from 'redis';

const redis = createClient();

async function isAllowed(clientId: string): Promise<boolean> {
  const result = await redis.eval(luaScript, {
    keys: [`rate_limit:${clientId}`],
    arguments: ['100', '10', '1', Date.now().toString()]
  });
  
  return result === 1;
}

Rate Limiting por Tier

Diferentes limites para diferentes clientes:

enum Tier {
  FREE = 100,
  PRO = 1000,
  ENTERPRISE = 10000
}

class TieredRateLimiter {
  private limiters: Map<Tier, TokenBucket> = new Map();

  constructor() {
    this.limiters.set(Tier.FREE, new TokenBucket(100, 1));
    this.limiters.set(Tier.PRO, new TokenBucket(1000, 10));
    this.limiters.set(Tier.ENTERPRISE, new TokenBucket(10000, 100));
  }

  isAllowed(clientId: string, tier: Tier): boolean {
    return this.limiters.get(tier)!.isAllowed(clientId);
  }
}

Headers HTTP

Comunique rate limit ao cliente:

app.use(async (req, res, next) => {
  const allowed = await rateLimiter.isAllowed(req.ip);

  res.setHeader('X-RateLimit-Limit', '100');
  res.setHeader('X-RateLimit-Remaining', allowed ? '99' : '0');
  res.setHeader('X-RateLimit-Reset', Date.now() + 60000);

  if (!allowed) {
    res.status(429).json({ error: 'Too Many Requests' });
    return;
  }

  next();
});

Ferramentas Reais

Nginx

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

server {
    location /api/ {
        limit_req zone=mylimit burst=20;
    }
}

Express Rate Limit

import rateLimit from 'express-rate-limit';

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutos
  max: 100 // 100 requests por windowMs
});

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

AWS API Gateway

Resources:
  ApiGatewayUsagePlan:
    Type: AWS::ApiGateway::UsagePlan
    Properties:
      Throttle:
        BurstLimit: 200
        RateLimit: 100  # requests/second

Quando Usar Cada Algoritmo?

Conclusão

Rate Limiting não é sobre "bloquear usuários". É sobre proteger seu sistema de abuso e garantir fair usage.

Se sua API não tem rate limiting, você está a um script malicioso de derrubar produção.

Referências

1. Kong - "How to Design a Scalable Rate Limiting Algorithm" - https://konghq.com/blog/how-to-design-a-scalable-rate-limiting-algorithm
2. Stripe - "Rate Limiting" - https://stripe.com/docs/rate-limits
3. Redis Documentation - "Rate Limiting Pattern" - https://redis.io/commands/incr#pattern-rate-limiter
4. "System Design Interview" - Alex Xu

Caso real e métricas

Cenário: API pública evitando abuso. A ConnectAPI misturou sliding window para fairness + token bucket para bursting, registrando métricas por cliente.

Checklist de implementação

• Escolha algoritmo conforme bursting/justiça.
• Logue tokens consumidos e limites.
• Forneça feedback (headers) aos clientes.
• Teste cenários de abuso controlados.

Referências rápidas

• Cloudflare Rate Limiting
• Envoy throttling docs

1. O problema real por trás de rate limiting

Toda equipe acha que rate limiting é um detalhe de infraestrutura. Até o dia em que um cliente automatiza milhares de chamadas por minuto. Ou até o momento em que um bot descobre seu endpoint mais barato. Ou até a integração de um parceiro externo ignorar limites implícitos.

Rate limiting não existe para punir o usuário. Ele existe para proteger o sistema. Quando você deixa a API aberta sem política de consumo, você transfere risco para toda a plataforma. O custo aparece em CPU, memória, filas, cache, banco, observabilidade e suporte.

O padrão mais comum é este. O time começa com um endpoint simples. Depois adiciona autenticação. Depois adiciona paginação. Depois adiciona retries. Depois descobre que os retries dos clientes viram amplificação de tráfego. O incidente parece súbito. Na prática, ele foi plantado meses antes.

Rate limiting é um contrato. Ele define quanto um consumidor pode pedir. Ele define como bursts são tratados. Ele define como fairness é aplicado. Ele define o que acontece quando o sistema está sob pressão.

Se esse contrato não estiver explícito, a API vira aposta.

2. O que rate limiting realmente precisa resolver

Um bom limitador precisa responder cinco perguntas.

1. Quem está consumindo?
2. Quanto esse consumidor pode usar?
3. Em que janela de tempo?
4. Como lidar com bursts?
5. O que acontece quando o limite é excedido?

Essas perguntas parecem simples. Elas não são. Cada resposta cria trade-offs diferentes.

Se você usar uma janela fixa, ganha simplicidade e perde precisão. Se você usar uma janela deslizante, ganha justiça e perde custo de memória. Se você usar token bucket, ganha bursts controlados e perde previsibilidade de fila. Se você usar leaky bucket, ganha suavização e perde latência.

Não existe algoritmo perfeito. Existe algoritmo apropriado para uma intenção específica.

3. Leitura do problema com first principles

Comece do objetivo. Você quer evitar que um consumidor destrua a capacidade compartilhada.

Isso significa que a política precisa:

• limitar abuso deliberado
• conter bugs de clientes
• impedir loops agressivos de retry
• preservar fairness entre tenants
• proteger serviços downstream
• dar feedback claro para clientes legítimos

Se uma política não contribui para esses seis pontos, ela é cosmética.

Agora aplique a inversão. O que faria o rate limiting falhar?

• contar requests no lugar errado
• usar relógio inconsistente
• armazenar estado sem atomicidade
• esconder decisões do cliente
• bloquear usuários bons junto com maus
• esquecer de monitorar o impacto
• implementar algo que não escala horizontalmente

Se você desenhar o sistema para evitar esses erros, a solução fica muito melhor.

4. Os algoritmos em perspectiva

Fixed Window Counter

É o mais fácil de explicar. Você conta requests em blocos temporais.

O problema é a borda. Se a janela reinicia em um segundo exato, o cliente pode concentrar tráfego perto da transição. O resultado é um pico artificial.

Esse algoritmo funciona quando:

• a precisão não precisa ser alta
• o risco de burst na borda é aceitável
• você quer implementar algo rápido
• o contexto é interno e controlado

Ele falha quando:

• a API é pública
• o cliente pode automatizar bursts
• o limite precisa ser estrito

Sliding Window Log

É o mais preciso. Você armazena timestamps individuais. Para cada request, calcula quantas aconteceram nos últimos N milissegundos.

Esse algoritmo é forte porque elimina o problema de borda. Também é caro porque cresce com o volume de tráfego.

Ele funciona melhor quando:

• a taxa por cliente é baixa ou moderada
• a justiça temporal importa
• você consegue pagar memória e processamento

Sliding Window Counter

É o meio-termo. Você usa a janela atual e a anterior para estimar consumo com suavização.

Isso reduz o custo de armazenar todos os eventos. Também melhora o comportamento de borda.

Na prática, ele é um dos melhores compromissos para sistemas com grande escala.

Token Bucket

É o algoritmo mais versátil. Cada consumidor tem um balde com capacidade máxima. As requests consomem tokens. Os tokens se regeneram em uma taxa constante.

Isso permite burst controlado. Um cliente pode usar rapidamente sua cota acumulada. Depois precisa esperar o refill.

Esse modelo é ideal quando:

• burst curto é aceitável
• o sistema precisa ser amigável para picos normais
• você quer uma política intuitiva para consumidores

Leaky Bucket

Aqui você pensa em fila. As requests entram. Saem em taxa constante.

Esse algoritmo é ótimo para suavizar tráfego. Também cria mais latência. Por isso ele faz sentido quando o sistema downstream é sensível a variações.

5. Fixed window em detalhe

Fixed window parece ingênuo. Mas é útil. Ele é simples de implementar. Ele é fácil de explicar. Ele é barato para observar.

O risco está na janela. Se o seu limite for 100 req/min, um cliente pode fazer 100 requests no fim do minuto e mais 100 no começo do seguinte. Isso gera 200 requests em segundos.

Esse efeito chama-se burst de borda. Ele é aceitável em alguns cenários. Ele é perigoso em outros.

Implementação mental

Você precisa de:

• chave de cliente
• contador por janela
• início da janela
• reset quando a janela expira

Quando usar

• protótipo
• ambiente interno
• limitação aproximada
• controle coarse-grained

Quando não usar

• public APIs com abuso real
• billing-sensitive endpoints
• serviços que precisam de fairness estrita

6. Sliding window log em detalhe

Esse algoritmo é conceitualmente elegante. Ele responde à pergunta certa. Quantas requests ocorreram agora, olhando para trás em N milissegundos?

O custo é claro. Você precisa armazenar timestamps. Você precisa limpar eventos antigos. Você precisa decidir se a limpeza acontece no read, no write ou em background.

Em sistemas de grande volume, isso pode virar custo operacional pesado.

Vantagem prática

Ele é excelente para auditoria. Você consegue reconstruir consumo com precisão. Isso é bom para debug. Isso é bom para disputa de quota. Isso é bom para investigar comportamento suspeito.

Desvantagem prática

Ele é mais caro do que parece. Se um cliente estiver chamando a API sem parar, a fila de timestamps cresce. Isso vira pressão de memória. Também pode virar pressão de GC em runtimes gerenciados.

7. Sliding window counter em detalhe

Esse algoritmo tenta reduzir o custo do log. Em vez de guardar todos os timestamps, ele usa agregação.

O truque é simples. Você mede a janela atual. Você mede a janela anterior. Depois combina os dois com um peso proporcional ao tempo restante.

Isso entrega uma aproximação boa o bastante para muitos casos. É mais barato que o log puro. É mais justo que o fixed window.

Onde ele brilha

• APIs com muito tráfego por cliente
• limites em alto volume
• necessidade de menor uso de memória

Onde ele falha

• casos que exigem precisão absoluta
• cenários de disputa legal ou faturamento muito rigoroso

8. Token bucket em detalhe

Token bucket merece atenção porque ele é o mais útil no mundo real. Ele modela comportamento humano melhor do que janelas rígidas. Usuários legítimos não fazem tráfego em linha reta. Eles têm bursts. Eles navegam. Eles clicam. Eles automatizam em grupos.

Token bucket aceita isso. Ao mesmo tempo, impede abuso sustentado.

Intuição

Imagine um balde que comporta 100 tokens. Ele recebe 10 tokens por segundo. Cada request custa 1 token. Se o cliente não usar nada por um tempo, o balde enche. Se ele fizer um burst, ele consome o estoque acumulado. Depois precisa esperar reposição.

Consequência

Isso é muito bom para:

• APIs públicas
• consumo por humano
• integrações com burst normal
• filas de processamento com elasticidade

Perigo

Se você configurar capacidade demais, o burst vira excesso. Se configurar refill demais, o limitador fica frouxo. Se configurar pouco, ele vira fricção.

9. Leaky bucket em detalhe

Leaky bucket é mais próximo de uma fila controlada. Requests entram. O sistema libera em velocidade constante.

Isso suaviza carga. Isso protege recursos downstream. Isso torna latência mais previsível.

Mas há um preço. A fila introduz atraso. Se o usuário espera resposta imediata, o algoritmo pode piorar UX.

Melhor uso

• streaming controlado
• pipelines de processamento
• proteção de serviços lentos
• tráfego onde suavização vale mais que burst

10. Comparação prática

Essa tabela não decide por você. Ela só expõe o custo.

11. Rate limiting por identidade

Você precisa definir o sujeito da política.

Pode ser:

• IP
• user id
• API key
• tenant id
• organization id
• device id
• route + identity

Cada opção muda o efeito da política.

IP é fácil. IP também é ruim em redes compartilhadas.

API key é melhor para parceiros. API key não resolve abuso dentro do tenant.

Tenant id é bom para SaaS. Tenant id exige modelagem clara de quota e subquota.

O ponto é simples. Sem identidade correta, você limita a pessoa errada.

12. Hierarquia de limites

Sistemas maduros não têm um único limite. Eles têm camadas.

• limite global da plataforma
• limite por tenant
• limite por usuário
• limite por rota
• limite por operação sensível
• limite por região

Essa hierarquia evita um problema comum. Se você só limitar o usuário final, um tenant inteiro pode saturar uma rota compartilhada. Se você só limitar a rota, um tenant pode monopolizar o orçamento.

13. Distribuição e consistência

Em um sistema distribuído, o limitador não vive sozinho. Ele precisa sobreviver a múltiplas instâncias da aplicação.

Isso traz uma pergunta crítica. Onde fica o estado?

Opções comuns:

• memória local
• Redis
• banco relacional
• edge gateway
• proxy reverso
• serviço dedicado

Memória local é rápida. Memória local quebra consistência horizontal.

Redis é o ponto de equilíbrio mais comum. Redis oferece atomicidade suficiente com Lua. Redis também adiciona dependência operacional.

Banco relacional é bom para consistência. Banco relacional pode ser caro para alta frequência.

Gateway e proxy são bons para enforcement na borda. Isso reduz ida e volta para o backend.

14. Redis como store de rate limit

Redis aparece muito porque ele resolve um problema específico. Você precisa de leitura, escrita e incremento com atomicidade.

Um limitador distribuído precisa evitar race condition. Se duas instâncias checam o limite ao mesmo tempo, ambas podem permitir a request. Isso viola a política.

Lua scripts ajudam porque o cálculo inteiro roda atomicamente no servidor Redis.

Padrões úteis

• INCR com TTL para contadores simples
• ZSET para logs de sliding window
• HASH para buckets por consumidor
• Lua para token bucket e cálculo composto

15. Token bucket com Redis e Lua

O padrão clássico:

1. Ler tokens e timestamp.
2. Calcular refill.
3. Deduzir custo.
4. Persistir estado.
5. Responder allowed/blocked.

O importante é que tudo isso aconteça atomically.

local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local refill_per_sec = tonumber(ARGV[2])
local cost = tonumber(ARGV[3])
local now = tonumber(ARGV[4])

local data = redis.call("HMGET", key, "tokens", "ts")
local tokens = tonumber(data[1]) or capacity
local ts = tonumber(data[2]) or now

local elapsed = math.max(0, now - ts)
local refill = (elapsed / 1000) * refill_per_sec
tokens = math.min(capacity, tokens + refill)

if tokens < cost then
  redis.call("HMSET", key, "tokens", tokens, "ts", now)
  redis.call("EXPIRE", key, 3600)
  return 0
end

tokens = tokens - cost
redis.call("HMSET", key, "tokens", tokens, "ts", now)
redis.call("EXPIRE", key, 3600)
return 1

Esse script é pequeno. Ele também é o tipo de coisa que economiza horas de dor.

16. Sliding window com Redis

Para sliding log, um ZSET funciona bem. Cada request vira um timestamp. Requests antigas são removidas com ZREMRANGEBYSCORE.

Esse padrão é preciso. Também é mais caro em grande escala.

local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window_ms = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local start = now - window_ms

redis.call("ZREMRANGEBYSCORE", key, 0, start)
local count = redis.call("ZCARD", key)

if count >= limit then
  return 0
end

redis.call("ZADD", key, now, now .. "-" .. redis.call("INCR", key .. ":seq"))
redis.call("EXPIRE", key, math.ceil(window_ms / 1000))
return 1

17. NGINX e rate limiting na borda

NGINX é útil quando você quer bloquear cedo. Quanto mais perto da borda a política estiver, menor o custo do abuso.

Isso reduz pressão em backend, banco e filas.

http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
    limit_req_status 429;

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

Quando faz sentido

• tráfego público
• defesa contra bots
• proteção inicial
• APIs simples

Limite

NGINX não sabe tudo sobre o negócio. Ele enxerga bem IP, host e path. Ele não enxerga quota de tenant sem integração adicional.

18. Envoy e rate limiting distribuído

Envoy é mais poderoso quando você precisa de uma camada de malha ou gateway. Ele suporta rate limit com serviço externo. Isso permite políticas mais ricas do que a borda estática consegue expressar.

O fluxo é simples.

1. Request chega.
2. Envoy consulta o serviço de rate limit.
3. Serviço decide allowed/blocked.
4. Envoy aplica a resposta.

Esse desenho permite centralizar política. Também cria dependência operacional no serviço de rate limit.

Benefícios

• enforcement central
• política por rota e contexto
• integração com service mesh
• observabilidade consistente

Riscos

• latência adicional
• dependência de um serviço crítico
• necessidade de fallback bem definido

19. API Gateway como ponto de política

API gateways oferecem uma forma prática de centralizar limites por consumidor. Isso é útil quando você tem muitos clientes externos.

Você pode aplicar:

• throttling por API key
• quotas mensais
• limites por rota
• planos de serviço
• prioridades

Mas gateway não substitui desenho de sistema. Ele só impõe políticas existentes. Se sua arquitetura downstream já está mal desenhada, o gateway vai apenas atrasar o colapso.

20. Fairness como objetivo

Rate limiting não serve apenas para bloquear abuso. Ele também serve para distribuir oportunidade.

Sem fairness, um tenant barulhento domina os recursos. Com fairness, cada consumidor recebe uma parcela previsível.

Isso é importante em:

• SaaS multi-tenant
• APIs com parceiros
• sistemas de fila compartilhada
• features com custo variável

Métricas de fairness

• taxa de bloqueio por tenant
• consumo por rota
• proporção entre quota contratada e uso real
• distribuição de latência por consumidor

21. Abuse resistance

Abuso não parece sempre ataque. Às vezes parece automação legítima. Às vezes parece bug de cliente. Às vezes parece retry sem backoff.

O sistema precisa distinguir:

• tráfego sincero e alto
• tráfego humano bursty
• tráfego automatizado
• tráfego malicioso

Nem sempre dá para identificar a intenção. Por isso as políticas precisam ser robustas mesmo quando a intenção é ambígua.

22. Adaptive rate limiting

Políticas adaptativas mudam limites com base em contexto.

Exemplos:

• aumentar tolerância para clientes com boa reputação
• reduzir quota quando um serviço downstream degrada
• apertar limites durante incidentes
• aplicar prioridade para tráfego essencial

Essa abordagem é poderosa. Também é perigosa. Se a política muda demais, clientes ficam sem previsibilidade.

Princípio de uso

Use adaptatividade para proteção. Não use para esconder falta de capacidade.

23. Backoff e retry

Rate limiting sem comunicação vira frustração. O cliente precisa saber o que fazer.

Por isso os headers importam.

• X-RateLimit-Limit
• X-RateLimit-Remaining
• X-RateLimit-Reset
• Retry-After

Se o cliente respeita o feedback, a experiência melhora. Se o cliente ignora, você ainda precisa estar protegido.

24. Idempotency e rate limiting

Alguns sistemas sofrem porque clientes enviam retries de forma agressiva. O melhor antídoto é combinar rate limit com idempotency keys.

Rate limit protege capacidade. Idempotency protege semântica.

Sem idempotency, um retry pode virar duplicação de pedido. Sem rate limiting, um bug de retry pode virar avalanche.

25. Observabilidade do limitador

Um rate limiter invisível vira caixa-preta. Você precisa observar:

• allowed count
• blocked count
• top consumers
• tokens remaining
• latency do check
• erros do backend de estado
• falsos positivos

Se você não medir isso, vai operar no escuro.

Painel mínimo

• requests allowed por rota
• requests blocked por tenant
• distribuição de custo por identity
• p95 do check de rate limiting
• top IPs e keys bloqueadas

26. Alertas que realmente importam

Alertar em excesso também é falha. O ideal é alertar quando:

• bloqueios sobem abruptamente
• latência do check dispara
• o backend de estado falha
• o limite é atingido por muitos tenants ao mesmo tempo
• o sistema mostra burst não previsto

Se o alerta não ajuda ação operacional, ele vira ruído.

27. Failure modes

27.1 Clock skew

Se você usa timestamps e os relógios divergem, a política pode ficar incoerente. Use clock monotônico quando possível. Quando não for possível, trate o tempo com cuidado.

27.2 Redis outage

Se o backend de estado cai, o que acontece?

• fail open
• fail closed
• degrade with local fallback

Cada escolha tem implicação. Fail open preserva disponibilidade. Fail closed preserva proteção. O correto depende do risco do endpoint.

27.3 Hot key

Uma chave popular pode virar gargalo. Isso acontece quando um único tenant ou IP concentra tráfego.

Mitigações:

• sharding de keys
• hash tags
• cache local de leitura
• limites por dimensão adicional

27.4 Thundering herd

Quando muitos clientes recebem 429 ao mesmo tempo, eles podem voltar juntos. Isso piora o pico.

Mitigação:

• jitter no retry
• Retry-After
• mensagens claras
• backoff exponencial no cliente

28. Rollout seguro

Não lance política agressiva de uma vez. O rollout certo é gradual.

1. Observe sem bloquear.
2. Logue decisões.
3. Aplique shadow mode.
4. Bloqueie apenas um segmento pequeno.
5. Expanda por tenant ou rota.
6. Revise o falso positivo.

Esse ritmo reduz risco operacional. Também aumenta confiança do time.

29. Shadow mode

Shadow mode é subestimado. Ele permite calcular a decisão sem impactar o fluxo.

Você consegue responder:

• quantos requests seriam bloqueados?
• quais tenants seriam mais afetados?
• qual regra é agressiva demais?

Essa visão evita quebra prematura.

30. Caso realista

Imagine uma API de relatórios. O time percebe que certos clientes dispararam exportações em massa. O banco começou a saturar. As filas cresceram. O time precisava agir sem matar clientes legítimos.

Estratégia aplicada

• token bucket por tenant
• limite adicional por export route
• burst curto permitido
• fallback para cache pré-gerado
• headers de explicação
• observabilidade por tenant

Resultado

• menos pressão no banco
• menos incidentes de timeout
• clientes entenderam o motivo do bloqueio
• o time conseguiu diferenciar abuso de uso legítimo

31. UI e UX do 429

429 não é só um status. É uma mensagem de produto.

A resposta deve ser clara.

Bom exemplo:

{
  "error": "rate_limit_exceeded",
  "message": "You have reached your request limit for this minute.",
  "retryAfterSeconds": 12
}

Ruim exemplo:

{
  "error": "Too Many Requests"
}

O usuário precisa de contexto. Sem isso, ele vai tentar de novo do mesmo jeito.

32. Quotas e pricing

Rate limiting também é instrumento comercial. Em SaaS, quota define embalagem de valor.

Você pode separar:

• free tier
• trial tier
• pro tier
• enterprise tier

O erro comum é misturar proteção com monetização de forma confusa. Se a política de preço e a política de proteção estiverem misturadas, o suporte paga a conta.

33. Limites por rota

Nem toda rota custa o mesmo.

• leitura simples custa pouco
• busca custa mais
• exportação custa muito
• criação de recursos pode acionar downstream caro

Logo, o limite precisa refletir custo. Limite igual para tudo é elegante. Também é ingênuo.

34. Limites por custo

Alguns sistemas usam weighted cost. Uma request simples custa 1. Uma exportação custa 10. Uma operação com múltiplos writes custa 5.

Esse modelo é mais justo. Também exige disciplina para manter os pesos.

35. GraphQL e rate limiting

GraphQL complica o jogo. Uma única query pode custar pouco ou muito. Você precisa medir complexity, depth ou resolver cost.

O limite não pode olhar apenas para a URL. Ele precisa olhar para o shape da operação.

Isso evita que uma query aparentemente pequena consuma recursos excessivos.

36. Streaming e rate limiting

Em streaming, limitar requests não basta. Você também precisa limitar conexões, mensagens, frames ou eventos por janela.

SSE, WebSocket e Kafka têm dinâmicas diferentes. O algoritmo precisa respeitar isso.

Exemplo

• WebSocket: limite de conexões e mensagens por minuto
• SSE: limite de assinaturas ativas
• Kafka producer: limite de produção por tópico e tenant

37. Multi-region

Quando você opera globalmente, surge latência. Se o rate limit depende de um backend central, a decisão fica mais lenta.

Opções:

• limitar localmente por região
• sincronizar quotas assíncronas
• aceitar pequena divergência
• usar edge enforcement

O trade-off é inevitável. Mais consistência global geralmente custa mais latência.

38. Edge enforcement

Bloquear no edge é poderoso. Você corta tráfego cedo. Você reduz custo de transporte. Você protege origem.

Mas edge policy costuma ser mais simples. Ela não conhece todos os detalhes do domínio.

Então o ideal é combinar:

• política simples no edge
• política detalhada no gateway
• política contextual no backend

39. Testes

Um rate limiter sem teste é um incêndio esperando acontecer.

Teste:

• bursts na borda da janela
• concorrência alta
• clock skew
• perda de backend
• retry agressivo
• múltiplas identidades
• recuperação após TTL

Propriedades que importam

• monotonicidade do contador
• atomicidade da decisão
• isolamento entre keys
• estabilidade com tempo
• ausência de aprovação dupla em race condition

40. Benchmarking

Faça benchmark do limitador com carga realista. Não teste só happy path.

Mensure:

• throughput
• p95 da decisão
• consumo de memória
• custo do backend
• impacto por algoritmo

Isso evita otimização cega.

41. Checklist de produção

• política por identidade definida
• estratégia de burst escolhida
• backend de estado com atomicidade
• headers de resposta implementados
• logs estruturados disponíveis
• métricas de allowed e blocked
• fallback definido para outage
• testes de borda e concorrência
• rollout gradual planejado
• documentação para clientes

42. Quando não limitar

Nem toda rota precisa de limitador rígido.

Se a rota é interna e isolada. Se o custo é mínimo. Se o endpoint já está protegido por outra camada. Se o limite adicionaria fricção sem ganho real.

Nesses casos, simplifique. Boa engenharia também é saber onde não adicionar política.

43. Anti-padrões

• usar IP como única identidade para tudo
• implementar limite sem Retry-After
• bloquear sem explicar
• usar estado não atômico
• misturar quota de billing com proteção de abuso
• esquecer observabilidade
• aplicar mesma regra para rotas de custos muito diferentes

44. Conclusão técnica

Rate limiting é uma disciplina de proteção. Ele equilibra justiça, capacidade e experiência. Ele precisa de algoritmo certo, identidade certa, observabilidade certa e fallback certo.

Se você trata rate limiting como detalhe, ele vira incidente. Se você trata como contrato, ele vira vantagem operacional.

45. Referências principais

• Kong - How to Design a Scalable Rate Limiting Algorithm
• Redis Documentation - Rate Limiting Pattern
• Cloudflare Rate Limiting docs
• Envoy rate limit service docs
• NGINX limiting request docs
• AWS API Gateway usage plans

46. Mini FAQ

Qual algoritmo devo escolher primeiro?

Token bucket. Ele é o melhor ponto de partida para a maioria das APIs.

Qual algoritmo é mais justo?

Sliding window log. Ele é mais preciso, mas custa mais.

Qual algoritmo é mais simples?

Fixed window counter. Mas ele é o que mais sofre com borda.

Posso usar memória local?

Pode. Só não finja que isso resolve consistência horizontal.

O que eu devo monitorar?

Allowed, blocked, latency do check, top consumers, erros do backend e falsos positivos.

47. #newshortarticle

Portuguese

Título: Rate limiting algorithms: proteja sua API antes que o abuso apareça

Resumo: Rate limiting não é só bloquear requests. É uma política de proteção que controla bursts, fairness e capacidade em APIs e sistemas distribuídos. Token bucket, leaky bucket e sliding window resolvem problemas diferentes. A escolha certa depende de custo, latência e previsibilidade.

Pontos-chave

• Token bucket aceita bursts e é o melhor ponto de partida.
• Sliding window é mais justo, mas custa mais.
• Leaky bucket suaviza tráfego e adiciona latência.
• Redis com Lua resolve atomicidade em ambiente distribuído.
• Headers como Retry-After melhoram a experiência do cliente.

CTA

Se sua API ainda não tem política explícita de limite, você já está operando com risco desnecessário.

English

Title: Rate limiting algorithms: protect your API before abuse shows up

Summary: Rate limiting is not just about blocking requests. It is a protection policy that controls bursts, fairness, and capacity in APIs and distributed systems. Token bucket, leaky bucket, and sliding window solve different problems. The right choice depends on cost, latency, and predictability.

Key points

• Token bucket allows bursts and is the best starting point.
• Sliding window is fairer, but more expensive.
• Leaky bucket smooths traffic and adds latency.
• Redis with Lua solves atomicity in distributed deployments.
• Headers like Retry-After improve client behavior.

CTA

If your API still has no explicit limit policy, you are already carrying unnecessary risk.