Definición
El rate limiting consiste en limitar cuántas peticiones puede hacer un cliente en un intervalo de tiempo. Superado el límite, el sistema rechaza las siguientes durante un rato.
Existe por tres motivos distintos, y conviene distinguirlos porque llevan a límites distintos:
Contra el abuso deliberado. Probar contraseñas a lo bruto, extraer tu catálogo entero, inundar un formulario de spam.
Contra el error ajeno. Una integración con un fallo que llama mil veces por minuto sin querer. Ocurre más que el abuso.
Para repartir capacidad. Que un cliente intensivo no degrade el servicio de los demás.
Cómo se define un límite
Un límite son siempre dos números y un sujeto: cuántas peticiones, en cuánto tiempo, por quién.
El sujeto es la decisión más importante:
- Por dirección IP. Simple, y castiga a oficinas enteras que salen por la misma IP.
- Por cuenta de usuario. Más justo, y solo sirve si hay identificación.
- Por clave de API. Lo normal en integraciones.
- Combinado, que es lo que acaba haciéndose en serio: límites distintos según quién llama y qué llama.
Y el límite no es uno para todo el sistema. Un buscador puede permitir muchas peticiones por minuto; un formulario de contacto o un intento de login, muy pocas.
Ejemplo práctico
En los formularios que envían un correo o crean un registro, el rate limiting es lo que separa una bandeja de entrada útil de una llena de basura.
Lo que aprendí montándolos: los límites que funcionan son agresivamente bajos en los sitios adecuados. Un formulario de contacto legítimo se envía una vez, quizá dos. Permitir tres o cuatro envíos al día por dirección IP no molesta a nadie real y corta en seco casi todo el ruido automatizado.
Y funciona todavía mejor combinado con dos medidas baratas:
Un campo trampa invisible para las personas y tentador para los robots: si viene relleno, se descarta la petición sin decir nada.
Distinguir el tráfico automatizado por sus propias señales, para no contaminar las estadísticas ni las alertas.
El segundo aprendizaje, sobre cómo se rechaza: un límite superado debe responder con el código de estado correcto —el que significa «demasiadas peticiones»— y con una cabecera que indique cuándo se puede reintentar. Devolver un error genérico, o peor, quedarse en silencio, obliga a quien integra a adivinar, y lo normal es que reintente inmediatamente y empeore las cosas.
Y del otro lado: si tú consumes una API ajena, respeta sus límites. Reintentar de inmediato tras un rechazo es la forma más rápida de que te bloqueen la clave. Lo correcto es esperar cada vez más entre intentos.
Y una advertencia sobre lo que el rate limiting no resuelve: no es una defensa contra un ataque distribuido a gran escala, porque miles de orígenes distintos no superan ningún límite individual. Para eso hacen falta capas anteriores —un CDN o un cortafuegos de aplicación—. El rate limiting protege de un abusador, no de una avalancha.
Errores comunes
- No tenerlo en el login. Es el sitio donde más falta hace.
- Un único límite global para endpoints con costes muy distintos.
- Limitar solo por IP en un servicio con usuarios identificados.
- No decir cuándo reintentar.
- Límites tan estrictos que rompen el uso normal.
- Contar mal la ventana, de modo que se puede duplicar el límite justo en el cambio de intervalo.
- No registrar los bloqueos. Un pico de rechazos es una señal que conviene ver. Ver observabilidad.
Cuándo aplicarlo
En todo endpoint público: login, registro, recuperación de contraseña, formularios, búsqueda y cualquier API abierta.
La regla práctica: si una operación envía un correo, escribe en base de datos o cuesta dinero, necesita límite. Y conviene ponerlo el día que se publica, no el día que llega el primer abuso.
