¿Cómo funcionan el rate limiting y el HTTP caching en una REST API?

Question

IT Interview Practice · Accepted Answer

El rate limiting protege al server de demasiados requests; el HTTP caching evita repetir trabajo para requests que ya ha respondido. Ambos están estandarizados en HTTP y ambos son esenciales para una API en producción a escala.

## Rate limiting

El server limita cuántos requests puede hacer un client por ventana y devuelve **`429 Too Many Requests`** cuando se excede. Anuncia los límites vía cabeceras para que un client bien educado pueda autolimitarse:

```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" }
```

La cabecera `Retry-After` le dice al client exactamente cuánto esperar. Algoritmos comunes: **token bucket** (permite ráfagas hasta el tamaño del bucket, se recarga de forma constante — la elección habitual), **sliding window**, y **fixed window** (el más simple pero con ráfagas en los bordes de la ventana). Las keys suelen ser por API key, user, o IP, con contadores en Redis para una flota distribuida.

## HTTP caching

Dos mecanismos complementarios:

**1. Expiración (`Cache-Control`)** — el server dice cuánto tiempo una response permanece fresca, de modo que el client/CDN la reutiliza **sin ningún request en absoluto**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validación (`ETag` / conditional requests)** — cuando la frescura es incierta, el client revalida de forma barata. El server etiqueta una response con un **`ETag`** (una huella de versión); el client lo devuelve en `If-None-Match`, y si no ha cambiado el server devuelve **`304 Not Modified`** **sin body**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← body vacío, ahorra ancho de banda
```

```text
Fresh (within max-age)   → served from cache, 0 requests
Stale but ETag matches   → 304, tiny response, no re-render
Stale and changed        → 200 with new body + new ETag
```

Los ETags también dan poder a la **optimistic concurrency**: envía `If-Match: "a1b2c3"` en un `PUT`, y el server devuelve `412 Precondition Failed` si alguien más cambió el recurso primero — previniendo actualizaciones perdidas.

## Por qué es importante

Juntos, así es como una REST API sobrevive a la escala, así que los entrevistadores senior los usan para comprobar la madurez operativa. Para el rate limiting, la señal es que lo tratas como un **contrato cooperativo** — exponiendo cabeceras `RateLimit-*` y `Retry-After` para que los clients se echen atrás con elegancia en lugar de estrellarse contra un muro — y que puedes nombrar un algoritmo y dónde vive el contador (Redis, por key) en un despliegue distribuido. Para el caching, la idea clave es el **modelo de dos niveles**: la expiración (`max-age`) elimina el request por completo, mientras que la validación (`ETag`/`304`) hace que los requests inevitables sean baratos saltándose el body. Mencionar que los ETags cumplen doble función para la **optimistic concurrency** (`If-Match` → `412`) demuestra un dominio más profundo de la semántica de HTTP. Los candidatos que entienden estos mecanismos son los que pueden construir APIs que se mantienen rápidas y estables bajo tráfico real, que es exactamente lo que la pregunta está evaluando.

Rate limiting

HTTP caching

Por qué es importante

Preguntas relacionadas