Rate Limiting y Throttling para APIs

Langdock ofrece actualmente límites que van desde 60 000 tokens por segundo hasta otras restricciones. A primera vista parece un límite generoso, pero cuando trabajas con él, la realidad es bien distinta. Múltiples archivos, varias solicitudes, consultas rápidas, proveedores de API sin soporte para historial de conversaciones: hay muchas razones por las que puedes exceder el límite de repente. Si eres proveedor de API, necesitas mantener tu servicio en funcionamiento sin permitir que un cliente activo abrume el sistema y degrade el rendimiento para todos. ¿Qué opciones tienes?

Rate Limiting y Throttling en APIs

Rate Limiting y Throttling protegen las APIs contra sobrecarga, abuso y patrones de uso injustos limitando la cantidad de solicitudes.

Descripción compacta

Rate Limiting y Throttling son mecanismos que controlan cuántas solicitudes llegan a una API dentro de un período. Rate Limiting establece cuántas solicitudes puede enviar un cliente y rechaza el exceso, generalmente con el código de estado 429 Too Many Requests. Throttling reduce la velocidad de procesamiento para aliviar sistemas backend bajo carga elevada y asegurar tiempos de respuesta consistentes. Ambas técnicas protegen contra ataques de fuerza bruta, scraping, picos de carga accidentales y ataques de negación de servicio. Las implementaciones se basan en algoritmos como Fixed Window, Sliding Window, Token Bucket o Leaky Bucket. Las medidas de acompañamiento incluyen encabezados HTTP informativos, especificaciones de Retry-After, límites diferenciados por endpoint o usuario, y monitoreo de límites.

Componentes clave

Rate Limiting

Rate Limiting restringe cuántas solicitudes puede enviar un cliente dentro de una ventana de tiempo definida. Si el cliente excede el límite, la solicitud se rechaza. El límite puede aplicarse globalmente, por API, por endpoint, por cliente o por cuenta de usuario.

Throttling

Throttling reduce la velocidad a la que se procesan las solicitudes sin rechazarlas inmediatamente. Se utiliza cuando los sistemas backend están temporalmente sobrecargados o cuando necesitas asegurar un procesamiento uniforme. Throttling se implementa mediante colas, backoff o procesamiento ralentizado.

Fixed Window

El algoritmo Fixed Window cuenta solicitudes en ventanas de tiempo fijas, por ejemplo cada minuto u hora. Es simple de implementar, pero puede causar picos de solicitudes al final e inicio de cada ventana.

Sliding Window

El algoritmo Sliding Window considera una ventana de tiempo móvil y evita picos en los bordes de la ventana. Es más justo que Fixed Window, pero un poco más complejo de implementar.

Token Bucket

El algoritmo Token Bucket llena un contenedor con tokens a velocidad constante. Cada solicitud consume un token. Mientras haya tokens disponibles, se procesan las solicitudes. Cuando el contenedor está vacío, se rechaza o retrasa la solicitud. Token Bucket permite picos puntuales pero mantiene la tasa a largo plazo controlada.

Leaky Bucket

El algoritmo Leaky Bucket coloca las solicitudes en una cola y las procesa a velocidad constante. Suaviza picos de tráfico de manera muy efectiva y evita brotes. Es excelente para procesamiento uniforme, pero puede generar tiempos de espera.

Código de estado HTTP 429

Cuando un cliente excede el Rate Limit, el servidor responde con 429 Too Many Requests. El encabezado Retry-After indica al cliente cuándo puede reintentar la solicitud. Esto permite reintentos justos y reduce la carga.

Encabezados de límite

Encabezados informativos como X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset ayudan a los clientes a entender su uso actual y planificar solicitudes. Mejoran la experiencia del desarrollador y evitan excesos accidentales.

Límites por usuario y por endpoint

Los límites globales son simples pero frecuentemente demasiado burdos. Es mejor usar límites diferenciados por usuario autenticado, por cliente o por endpoint. Los planes gratuitos pueden tener límites más estrictos, mientras que los clientes de pago obtienen cuotas mayores.

Load Shedding

Load Shedding es una forma de Throttling en la que se descartan activamente solicitudes bajo carga extrema para mantener el sistema estable. Priorizar solicitudes importantes y prescindir de operaciones menos críticas ayuda a mantener el sistema funcionando.

Rate Limiting distribuido

En sistemas distribuidos, Rate Limiting debe funcionar de forma consistente entre múltiples instancias. Para esto se utilizan almacenes centralizados como Redis o bases de datos. Alternativamente, pueden emplearse técnicas de aproximación como Sliding Window Log en Redis.

Monitoreo y alertas

Supervisa con qué frecuencia se activan los límites, qué clientes se ven afectados y si los picos indican ataques o errores. Las alertas ante patrones inusuales permiten responder rápidamente ante abuso o problemas de capacidad.

Ejemplo práctico

Un proveedor de API limita solicitudes usando el algoritmo Token Bucket. Cada usuario autenticado dispone de 100 tokens por minuto, con un brote máximo de 20 tokens.

Solicitud:

GET /api/v1/products
Authorization: Bearer USER_TOKEN

Respuesta exitosa:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1751300000

Respuesta cuando se excede el límite:

HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1751300000

{
  "type": "https://api.example.com/problems/rate-limit-exceeded",
  "title": "Rate Limit excedido",
  "status": 429,
  "detail": "Has excedido el límite de 100 solicitudes por minuto."
}

El cliente puede usar los encabezados y el valor Retry-After para determinar cuándo enviar la siguiente solicitud.

FAQ: Rate Limiting y Throttling

1. ¿Qué es Rate Limiting?

Rate Limiting restringe cuántas solicitudes puede enviar un cliente a una API en un período determinado. Los excesos se rechazan generalmente con 429 Too Many Requests.

2. ¿Qué es Throttling?

Throttling reduce la velocidad de procesamiento de solicitudes para proteger sistemas backend y garantizar tiempos de respuesta uniformes. Las solicitudes no se rechazan inmediatamente, sino que se ralentizan o se encolan.

3. ¿Cuál es la diferencia entre Rate Limiting y Throttling?

Rate Limiting rechaza solicitudes cuando se excede un límite. Throttling ralentiza el procesamiento sin rechazar solicitudes directamente. Ambas protegen contra sobrecarga.

4. ¿Qué es el algoritmo Token Bucket?

Token Bucket llena un contenedor con tokens a velocidad constante. Cada solicitud consume un token. Cuando el contenedor está vacío, la solicitud se rechaza. El algoritmo permite picos cortos.

5. ¿Qué es el algoritmo Leaky Bucket?

Leaky Bucket coloca solicitudes en una cola y las procesa a velocidad constante. Suaviza picos de tráfico muy eficazmente pero puede generar tiempos de espera.

6. ¿Qué es Fixed Window?

Fixed Window cuenta solicitudes en ventanas de tiempo fijas. Es simple, pero puede causar picos al final e inicio de cada ventana.

7. ¿Qué es Sliding Window?

Sliding Window considera una ventana de tiempo móvil y es más justo que Fixed Window. Evita picos en los bordes pero es algo más complejo.

8. ¿Qué significa HTTP 429?

HTTP 429 Too Many Requests indica que el cliente ha excedido el Rate Limit. El servidor puede informar mediante Retry-After cuándo puede reintentar el cliente.

9. ¿Qué es Retry-After?

Retry-After es un encabezado HTTP que indica al cliente cuánto tiempo debe esperar antes de reintentar una solicitud. Se usa con 429 y 503.

10. ¿Qué es Load Shedding?

Load Shedding descarta solicitudes bajo carga extrema para mantener el sistema estable. Las solicitudes importantes se priorizan y las menos críticas se rechazan.

11. ¿Cómo se implementa Rate Limiting en sistemas distribuidos?

En sistemas distribuidos se utiliza un almacén centralizado como Redis para mantener límites consistentes entre todas las instancias. Algoritmos como Sliding Window Log o Token Bucket se pueden implementar en Redis.

12. ¿Qué son límites por usuario?

Los límites por usuario se aplican a cada usuario autenticado. Son más justos que los límites globales porque consideran el comportamiento individual y aíslan el abuso.

13. ¿Qué es un burst?

Un burst es una ráfaga corta de solicitudes en muy poco tiempo. Algoritmos como Token Bucket permiten intencionalmente bursts siempre que la tasa a largo plazo permanezca controlada.

14. ¿Debería Rate Limiting ser diferente por endpoint?

Sí, diferentes endpoints tienen diferentes costos. Las operaciones de escritura y consultas intensivas en datos suelen necesitar límites más estrictos que operaciones simples de lectura.

15. ¿Por qué es importante el monitoreo para Rate Limiting?

El monitoreo muestra con qué frecuencia se activan límites, qué clientes se ven afectados y si los picos indican ataques o errores. Esto permite optimizar límites y capacidades.

Continuamos en la ruta de aprendizaje de APIs

El siguiente artículo en la ruta de aprendizaje de APIs cubre API Monitoring y Observability 2026, donde aprenderás a monitorear tus APIs usando métricas, logs y Distributed Tracing.

Referencias

Lecturas recomendadas para desarrollo de APIs

Si quieres profundizar en Rate Limiting, diseño de APIs y seguridad, te recomendamos los siguientes libros:

Keine Bücher für Kategorie "api-development" gefunden.

Täglicher Artikel