¿Cómo diseñas rate limiting?

Question

Accepted Answer

**Rate limiting** restringe cuántas solicitudes puede hacer un cliente en una ventana de tiempo — protegiendo sistemas del abuso, sobrecarga, y asegurando un uso justo. Es un componente común de diseño de sistemas, con varios algoritmos y consideraciones.

## Por qué es importante

```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)
```

## Consideraciones de implementación

```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 qué es importante

Entender cómo diseñar rate limiting es valioso porque es un **componente común de diseño de sistemas** para proteger sistemas y asegurar uso justo, por lo que es un conocimiento práctico importante.

Rate limiting — restringir cuántas solicitudes puede hacer un cliente en una ventana de tiempo — aborda necesidades importantes: **proteger contra abuso** (previniendo ataques como fuerza bruta, scraping, y DoS), **prevenir sobrecarga** (protegiendo la estabilidad del sistema), asegurar **uso justo** (ningún cliente monopolizando recursos, soportando límites escalonados como gratis vs pago), y control de costos.

Estos hacen que rate limiting sea un requisito común para APIs y servicios.

Entender los **algoritmos** y sus trade-offs — **ventana fija** (simple pero permitiendo ráfagas de frontera), **ventana deslizante** (más suave y precisa), **token bucket** (permitiendo ráfagas controladas mientras se limita la tasa promedio — popular y flexible), y leaky bucket (suavizando la salida) — es el conocimiento de diseño clave, ya que elegir el algoritmo correcto afecta el comportamiento.

Entender las **consideraciones de implementación** es particularmente importante: manejar **rate limiting distribuido** (límites compartidos entre múltiples servidores, comúnmente usando **Redis** para contadores atómicos rápidos compartidos entre instancias — ya que los límites por servidor no funcionan en sistemas distribuidos), identificar clientes (por API key, usuario, o IP), devolver respuestas claras (HTTP 429 con encabezados retry-after), elegir dónde aplicarlo (gateway, load balancer, o aplicación), y granularidad (por usuario, por endpoint, escalonado).

Estos reflejan diseñar rate limiting que funcione en sistemas distribuidos reales.

Rate limiting es un componente frecuentemente necesario, que aparece a menudo en discusiones de diseño de sistemas y entrevistas.

Ya que rate limiting es un componente común e importante para proteger sistemas (del abuso y sobrecarga) y asegurar uso justo, y ya que entender los algoritmos, sus trade-offs, e implementación especialmente distribuida (límites compartidos vía Redis) es importante para diseñarlo bien, entender cómo diseñar rate limiting es un conocimiento valioso y relevante para la práctica de diseño de sistemas — un componente común para proteger servicios y asegurar uso justo, requiriendo entendimiento de los algoritmos e implementación distribuida, y un tema frecuentemente discutido en diseño de sistemas para construir sistemas robustos y protegidos.