Como funcionam o rate limiting e o HTTP caching em uma REST API?

Question

IT Interview Practice · Accepted Answer

O rate limiting protege o server de requests demais; o HTTP caching evita repetir trabalho para requests que ele já respondeu. Ambos são padronizados no HTTP e ambos são essenciais para uma API de produção em escala.

## Rate limiting

O server limita quantos requests um client pode fazer por janela e retorna **`429 Too Many Requests`** quando excedido. Ele anuncia os limites via headers para que um client bem-comportado possa se autolimitar (self-throttle):

```http
HTTP/1.1 200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 12
RateLimit-Reset: 30
```

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 30

{ "error": "rate limit exceeded, retry in 30s" }
```

O header `Retry-After` diz ao client exatamente quanto tempo esperar. Algoritmos comuns: **token bucket** (permite bursts até o tamanho do bucket, reabastece de forma constante — a escolha usual), **sliding window**, e **fixed window** (o mais simples mas com bursts nas bordas da janela). As chaves geralmente são por API key, user, ou IP, com contadores no Redis para uma frota distribuída.

## HTTP caching

Dois mecanismos complementares:

**1. Expiração (`Cache-Control`)** — o server diz por quanto tempo uma response permanece fresca, então o client/CDN a reutiliza **sem request algum**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validação (`ETag` / conditional requests)** — quando a frescura é incerta, o client revalida de forma barata. O server marca uma response com uma **`ETag`** (uma impressão digital de versão); o client a envia de volta em `If-None-Match`, e se inalterada o server retorna **`304 Not Modified`** **sem body**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← body vazio, economiza banda
```

```text
Fresco (dentro do max-age)   → servido do cache, 0 requests
Stale mas o ETag combina     → 304, response minúscula, sem re-render
Stale e mudou                → 200 com body novo + ETag novo
```

As ETags também alimentam a **concorrência otimista (optimistic concurrency)**: envie `If-Match: "a1b2c3"` em um `PUT`, e o server retorna `412 Precondition Failed` se outra pessoa mudou o recurso primeiro — prevenindo lost updates.

## Por que isso importa

Juntos, é assim que uma REST API sobrevive à escala, então os entrevistadores senior os usam para checar a maturidade operacional. Para o rate limiting, o sinal é que você o trata como um **contrato cooperativo** — expondo headers `RateLimit-*` e `Retry-After` para que os clients recuem graciosamente em vez de baterem numa parede — e que você consegue nomear um algoritmo e onde o contador reside (Redis, por chave) em um deployment distribuído. Para o caching, o insight-chave é o **modelo de dois níveis**: a expiração (`max-age`) elimina o request por completo, enquanto a validação (`ETag`/`304`) torna os requests inevitáveis baratos ao pular o body. Mencionar que as ETags fazem dupla função na **concorrência otimista** (`If-Match` → `412`) mostra um domínio mais profundo da semântica do HTTP. Os candidatos que entendem esses mecanismos são os que conseguem construir APIs que permanecem rápidas e estáveis sob tráfego real, que é exatamente o que a pergunta está testando.

Rate limiting

HTTP caching

Por que isso importa

Perguntas relacionadas