¿Qué es rate limiting y cómo proteger una API de solicitudes excesivas?
Publicado el 2026-10-20 por frfrand
Qué es rate limiting, límites por usuario e IP, respuestas 429, ventanas temporales y cuándo puede perjudicar usuarios legítimos.
Rate limiting es una técnica que limita cuántas solicitudes puede realizar un cliente durante un período o bajo determinadas reglas. Se usa para proteger APIs, evitar abusos y repartir de manera razonable una capacidad que no es infinita.
Si alguien envía miles de peticiones por segundo a tu formulario de inicio de sesión, quizás no quieras que todas sean atendidas sin restricciones.
Una comparación con las entradas de un museo
Imaginá un museo con espacio para cien visitantes simultáneos. Si deja entrar a mil personas de golpe, la experiencia se vuelve mala para todos.
Los límites de solicitudes cumplen una función parecida: permiten administrar el ritmo de acceso para que un cliente muy activo no consuma todos los recursos del servicio.
Pero hay que evitar una política injusta. Si varias familias llegan en el mismo autobús, bloquearlas porque comparten una dirección de origen también sería un error.
¿Qué se puede limitar?
Podés establecer reglas por dirección IP, cuenta autenticada, token de API o tipo de endpoint. Cada alternativa presenta compromisos.
Limitar únicamente por IP puede afectar a personas que comparten una conexión residencial, corporativa o móvil. Limitar por usuario requiere identificarlo. Para endpoints críticos pueden aplicarse varias estrategias combinadas.
La lógica de negocio influye: consultar un producto público no cuesta lo mismo que generar un informe pesado o enviar un correo.
¿Cómo se implementa?
Una estrategia simple es permitir cierta cantidad de peticiones dentro de una ventana temporal. También existen modelos como token bucket, que permiten ráfagas controladas y recuperan capacidad progresivamente.
No hace falta memorizar las fórmulas para comprender el objetivo: establecer un ritmo sostenible sin castigar innecesariamente a los visitantes legítimos.
En sistemas con varios servidores, la coordinación importa. Si cada instancia cuenta solicitudes por separado, agregar instancias puede multiplicar accidentalmente el límite permitido.
¿Qué es el error HTTP 429?
Cuando un cliente supera la política, el servidor puede devolver el estado 429 Too Many Requests. Algunas respuestas incluyen Retry-After para indicar cuándo conviene volver a intentar.
La aplicación cliente debería respetar los límites y no reintentar en un bucle agresivo. De lo contrario, un sistema que está intentando protegerse recibirá todavía más tráfico.
Rate limiting y DDoS no son lo mismo
Los límites de aplicación ayudan con ciertos abusos, pero no siempre pueden detener un ataque volumétrico que satura la red antes de llegar a tu servidor.
Para esos escenarios son importantes defensas aguas arriba, redes de distribución y servicios especializados. El rate limiting es una capa, no una solución mágica contra todas las amenazas.
Ejemplo: una API de generación de informes
Una API permite exportar reportes que tardan veinte segundos en prepararse. Podés limitar la cantidad de trabajos simultáneos por cuenta y mover la generación a una cola.
Esto protege al servidor y evita que una persona lance cientos de trabajos idénticos accidentalmente. En lugar de devolver errores inesperados, el sistema puede informar que la tarea se programó o que se alcanzó temporalmente una cuota.
Errores habituales
Un límite idéntico para todas las rutas: una consulta de estado y una exportación costosa no tienen las mismas necesidades.
No explicar el rechazo: el cliente interpreta 429 como una caída si no sabe cuándo reintentar.
Bloquear por IP sin contexto: usuarios legítimos detrás de la misma red terminan afectados.
Confiar en el límite como autorización: una persona sin permisos no debería poder hacer una operación ni una sola vez.
¿Cómo aplicarlo en ArduMaker?
En una API desplegada sobre un VPS de ArduMaker, podés implementar límites en el backend o en un proxy compatible, considerando cuántas instancias existen y dónde se comparte el contador. Redis puede participar en ciertos diseños, aunque la elección exacta depende de la arquitectura.
En una frase: rate limiting permite decir «hasta aquí, por ahora» para proteger la disponibilidad del servicio. Funciona mejor cuando responde al coste real de cada acción y no se convierte en un obstáculo para usuarios legítimos.
Fuentes: RFC 6585: estado 429 · Cabecera Retry-After.