Como você projeta rate limiting?

Question

Accepted Answer

**Rate limiting** restringe quantas requisições um cliente pode fazer em uma janela de tempo — protegendo sistemas de abuso, sobrecarga e garantindo uso justo. É um componente comum de design de sistemas, com vários algoritmos e considerações.

## Por que isso importa

```text
✓ PROTECT against abuse → prevent attacks (brute force, scraping, DoS), excessive use
✓ PREVENT OVERLOAD → protect the system from being overwhelmed (stability)
✓ FAIR USAGE → ensure no single client monopolizes resources; tiered limits (free vs paid)
✓ COST control; protect downstream services
→ a common requirement for APIs and services.
```

## Algoritmos de rate limiting

```text
FIXED WINDOW → count requests per fixed time window (e.g. 100/minute); simple
  ✗ allows bursts at window boundaries (up to 2x at the edges)
SLIDING WINDOW → rolling time window → smoother, no boundary bursts (more accurate)
TOKEN BUCKET → tokens refill at a rate; each request takes a token → allows BURSTS up to
  the bucket size while limiting the average rate (popular, flexible)
LEAKY BUCKET → requests processed at a steady rate (smooths output)
```

## Considerações de implementação

```text
✓ DISTRIBUTED → limits must be shared across servers → use a centralized store (REDIS is
  common: atomic counters, fast, shared across instances)
✓ Identify the client → by API key, user ID, IP
✓ Return clear responses → HTTP 429 (Too Many Requests); include limit/retry-after headers
✓ Where → at the API gateway, load balancer, or application layer
✓ Granularity → per user, per endpoint, global; different tiers/limits
```

## Por que isso importa

Entender como projetar rate limiting é valioso porque é um **componente comum de design de sistemas** para proteger sistemas e garantir uso justo, então é conhecimento prático importante.

Rate limiting — restringir quantas requisições um cliente pode fazer em uma janela de tempo — aborda necessidades importantes: **proteção contra abuso** (prevenindo ataques como força bruta, scraping e DoS), **prevenção de sobrecarga** (protegendo a estabilidade do sistema), garantir **uso justo** (nenhum cliente monopolizando recursos, suportando limites escalonados como gratuito vs pago) e controle de custo.

Issos tornam rate limiting um requisito comum para APIs e serviços.

Entender os **algoritmos** e suas trade-offs — **fixed window** (simples mas permitindo picos de limite), **sliding window** (mais suave e preciso), **token bucket** (permitindo picos controlados enquanto limita a taxa média — popular e flexível) e leaky bucket (suavizando a saída) — é o conhecimento de design chave, pois escolher o algoritmo certo afeta o comportamento.

Entender as **considerações de implementação** é particularmente importante: lidar com **rate limiting distribuído** (limites compartilhados entre múltiplos servidores, comumente usando **Redis** para contadores atômicos rápidos compartilhados entre instâncias — pois limites por servidor não funcionam em sistemas distribuídos), identificar clientes (por chave de API, usuário ou IP), retornar respostas claras (HTTP 429 com headers retry-after), escolher onde aplicar (gateway, load balancer ou aplicação) e granularidade (por usuário, por endpoint, escalonado).

Issos refletem o design de rate limiting que funciona em sistemas distribuídos reais.

Rate limiting é um componente frequentemente necessário, aparecendo frequentemente em discussões e entrevistas de design de sistemas.

Por ser um componente comum e importante para proteger sistemas (contra abuso e sobrecarga) e garantir uso justo, e por ser importante entender os algoritmos, suas trade-offs e especialmente a implementação distribuída (limites compartilhados via Redis), entender como projetar rate limiting é valioso e praticamente relevante conhecimento de design de sistemas — um componente comum para proteger serviços e garantir uso justo, requerendo entendimento dos algoritmos e implementação distribuída, e um tópico frequentemente discutido em design de sistemas para construir sistemas robustos e protegidos.