miji.beLa limitación de tasa (Rate Limiting) es un mecanismo que establece un número máximo de peticiones a una API o servicio dentro de una ventana de tiempo. Se configura, por ejemplo, como "60 peticiones por minuto" o "1 000 peticiones por día", y las peticiones que superan el límite reciben una respuesta HTTP 429 (Too Many Requests). Ese código está definido en el RFC 6585 e indica al cliente que ha enviado demasiadas peticiones en un intervalo determinado.
Sus objetivos son tres: proteger el servidor (evitar caídas por avalancha de peticiones), garantizar la equidad (impedir que un solo usuario acapare los recursos) y controlar costes (limitar el consumo en servicios de pago por uso en la nube).
En los servicios de acortamiento de URL, la limitación de tasa se aplica en varios puntos: límite de peticiones a la API de acortamiento (para evitar la generación masiva de spam), límite de accesos a las URL acortadas (para mitigar ataques DDoS) y límite de intentos de inicio de sesión en el panel de administración (para prevenir ataques de fuerza bruta).
Existen cuatro algoritmos principales: ventana fija (el contador se reinicia cada minuto), ventana deslizante (se calcula continuamente el número de peticiones en el último minuto), token bucket (los tokens se reponen a velocidad constante y cada petición consume uno) y leaky bucket (las peticiones se procesan a velocidad constante y el excedente se encola).
Para los desarrolladores que consumen una API con limitación de tasa, es necesario consultar las cabeceras de respuesta y ajustar la frecuencia de peticiones según las peticiones restantes. Los nombres de esas cabeceras varían de un servicio a otro: formas como X-RateLimit-Limit o X-RateLimit-Remaining se han impuesto por costumbre, mientras que el juego estándar de cabeceras RateLimit sigue en elaboración en el IETF (en agosto de 2026 continúa como Internet-Draft). Ante una respuesta 429, si viene una cabecera Retry-After conviene esperar lo que indique antes de reintentar; si no viene, o si tras la espera el servidor sigue devolviendo 429, se añade un backoff exponencial que alarga la espera de forma progresiva. Son dos medidas distintas: respetar Retry-After no equivale por sí solo a un backoff exponencial.