Rate limiting (limitación de tasa)

El rate limiting (limitación de tasa) restringe con qué frecuencia un cliente puede llamar a una API, por ejemplo 100 solicitudes por minuto por API key. Las solicitudes que superan el límite se rechazan hasta que se reinicia la ventana. Protege el servicio frente a sobrecargas y abusos, evita que un cliente ruidoso deje sin recursos a los demás y frena ataques como la adivinación de contraseñas. El límite suele controlarse por API key, usuario, token o dirección IP.

Ejemplo

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{"error": "rate_limited", "message": "Try again in 30 seconds"}

429 Too Many Requests y Retry-After son HTTP estándar. Las cabeceras que informan de la cuota restante, como X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset, son una convención habitual pero no un estándar único, así que comprueba lo que documenta tu API.

Algoritmos habituales

• Ventana fija (fixed window): cuenta las solicitudes por minuto de reloj. Es sencillo, pero un cliente puede enviar una doble ráfaga en el límite entre dos ventanas.
• Ventana deslizante (sliding window): cuenta las solicitudes de los últimos N segundos, lo que suaviza ese efecto de frontera.
• Token bucket (cubo de tokens): los tokens se reponen a un ritmo constante y cada solicitud gasta uno, lo que permite ráfagas cortas hasta el tamaño del cubo sin dejar de imponer una tasa media.

Qué probar

• El límite en sí: envía límite + 1 solicitudes y comprueba que exactamente la sobrante recibe 429.
• Recuperación: pasado el Retry-After o el momento de reinicio, las solicitudes vuelven a funcionar.
• Alcance: el tráfico de un usuario o de una key no debe consumir la cuota de otro. Comprueba si los límites se aplican por key, por usuario o por IP, y si un cliente puede esquivarlos rotando algo barato.
• Endpoints sensibles: el login, el restablecimiento de contraseña y la verificación de OTP deberían tener límites más estrictos que las lecturas normales.
• Formato de respuesta: una solicitud rechazada devuelve 429 con un cuerpo útil, no un 500 ni una conexión colgada.
• Comportamiento del cliente: tus propios clientes reducen el ritmo y respetan Retry-After en lugar de reintentar en un bucle cerrado.

Rate limits y tu suite de tests

Los tests de API en paralelo y las pruebas de carga pueden activar límites similares a los de producción y fallar por motivos ajenos al cambio que se está probando. Usa keys dedicadas o límites ampliados en los entornos de prueba y, cuando una prueba de carga pretenda medir capacidad, asegúrate de estar midiendo el servicio y no el rate limiter.