Índice de la Noticia
Introducción al rate limiting
¿Alguna vez te has preguntado por qué, de repente, una página web te devuelve un mensaje de error
o te bloquea sin razón aparente, dejándote pensando “¿pero si solo quería consultar una página…”?
En la mayoría de los casos, la respuesta está en una práctica tan sencilla como eficiente: el
rate limiting, o limitación de frecuencia de peticiones.
El concepto es tan antiguo como el primer servidor web que empezó a recibir más solicitudes de las
que podía procesar. Para evitar saturaciones, abusos o ataques, los administradores de sistemas
crearon una barrera que regula cuántas peticiones puede hacer un usuario (o una IP) en un intervalo
de tiempo determinado. Si sobrepasas ese umbral, ¡zas! Te encuentras con un bloqueo temporal.
¿Por qué el rate limiting es tan importante?
La capacidad de un servidor no es infinita: memoria, CPU, conexiones de red, base de datos…
Todo recurso tiene un límite. El rate limiting cumple tres funciones clave:
- Protección contra abusos: impide que un mismo cliente acapare recursos.
- Defensa frente a ataques DDoS: las peticiones masivas e indiscriminadas se cortan de raíz.
- Garantía de calidad de servicio: se asegura la disponibilidad para el resto de usuarios.
Imagina un centro comercial con una sola caja registradora. Si permites que un cliente haga 100
compras seguidas mientras el resto espera, el caos está asegurado. En internet sucede algo similar:
sin limitación, unos pocos “clientes” colapsan el sistema.
Mecanismos más comunes de rate limiting
Existen varios algoritmos y técnicas para implementar el rate limiting. A continuación describimos
los más populares:
-
Token Bucket: cada cliente tiene un “depósito” de tokens por cada petición se
consume uno. Los tokens se recargan periódicamente. Si el depósito está vacío, no se puede seguir. -
Leaky Bucket: las peticiones entran a un embudo que “gotea” a velocidad constante.
Si entra más agua (peticiones) de la que gotea, el exceso se pierde o se descarta. -
Fixed Window: se asigna un contador de peticiones para bloques de tiempo fijos,
por ejemplo, 100 solicitudes cada minuto. Al llegar al final de la ventana, el contador se reinicia. -
Sliding Window: similar al anterior, pero la ventana se mueve dinámicamente con el
tiempo, ofreciendo un control más preciso.
Cada método tiene sus ventajas y sus inconvenientes, pero todos persiguen el mismo objetivo: evitar
picos de tráfico repentinos que perjudiquen la experiencia global.
¿Qué sucede cuando superas los límites?
Cuando un servidor detecta que has excedido tu cuota de peticiones, suele responder con el código
HTTP 429 (Too Many Requests). Es habitual encontrar mensajes del tipo:
“Has realizado demasiadas solicitudes en un periodo de tiempo muy breve. Por favor, inténtalo de nuevo más tarde.”
En otros casos, se recurre a bloqueos más drásticos:
- Listas negras temporales o permanentes de direcciones IP.
- Captcha obligatorio al detectar comportamiento sospechoso.
- Redirección a páginas informativas que explican el motivo del bloqueo.
Ejemplos de rate limiting en la práctica
Veamos algunos entornos donde el rate limiting es crítico:
-
APIs públicas (como las de GitHub):
imponen límites para que ningún desarrollador abuse de los recursos gratuitos. -
Servicios de pago (por ejemplo, Amazon API Gateway): ofrecen distintas capas de
suscripción con diferentes cuotas de peticiones. Más dinero, más peticiones. Más info en
AWS. - CDNs y WAFs (Cloudflare
limita accesos sospechosos para mitigar DDoS,
consulta su guía en sitio oficial).
¿Por qué a veces te bloquean sin razón?
Aunque tu intención sea completamente legítima, estos son algunos motivos por los que un sitio
web podría bloquearte “sin razón”:
- IP compartida: si trabajas tras un proxy o una VPN, puedes compartir dirección con otros usuarios que abusen.
- Automatizaciones rápidas: usar scripts o herramientas que envían peticiones demasiado seguidas.
- Errores de configuración: un ajuste demasiado estricto por parte del administrador.
- Patrones sospechosos: accesos concurrentes, macros de navegador, scrolls automáticos.
Como dijo un ingeniero de sistemas de Cloudflare:
“No pretendemos molestar al usuario legítimo, pero si un bot malicioso ingresa 1.000 peticiones en un segundo,
tenemos que actuar rápido.”
Cómo evitar ser bloqueado
Si te ha ocurrido alguna vez, aquí van unas recomendaciones para mantenerte dentro de los límites:
- Lee la documentación del servicio (APIs suelen indicar su rate limit).
- Implementa lógica de exponential backoff para reintentos tras un 429.
- Usa caché en cliente y servidor para evitar peticiones redundantes.
- Distribuye las solicitudes en el tiempo no hagas todo de golpe.
- Si trabajas en un equipo, escucha la recomendación de tu administrador de sistemas: a veces el límite interno es más bajo.
Conclusión
El rate limiting es una pieza fundamental de la infraestructura moderna. Asegura un entorno más
estable, justo y seguro para todos. Aunque a veces parezca que los bloqueos son arbitrarios, su
objetivo es proteger el servicio —y a sus usuarios— de sobrecargas o ataques.
Ahora que sabes qué es el rate limiting y por qué te puede tocar un bloqueo “sin motivo aparente”,
recuerda: con un poco de planificación, buenas prácticas de programación y empatía hacia los
recursos ajenos, podrás navegar más tranquilo y evitar esas sorpresas de “Too Many Requests”.
