Rate Limiting (Limitación de Frecuencia de Solicitudes y Protección de API)

1. Visión general del concepto y problema sistémico

Sin un mecanismo confiable de limitación de frecuencia de solicitudes, cualquier servicio web abierto o punto final de API está bajo constante amenaza de colapso técnico o financiero:

• Agotamiento Financiero (AI Billing Drain): un atacante o un script en bucle puede enviar 100,000 solicitudes a su ruta de generación de código o imágenes en 5 minutos, generando una factura de $5,000 en OpenAI o Anthropic.
• Fuerza Bruta y Credential Stuffing: botnets automáticos prueban millones de contraseñas en el formulario de inicio de sesión /api/auth/login, sobrecargando la base de datos con operaciones pesadas de hash bcrypt/Argon2.
• Caída en Cascada de la Base de Datos (Denial of Service): llamadas paralelas masivas a puntos finales de búsqueda no cacheados agotan el pool de conexiones de PostgreSQL, paralizando el funcionamiento de toda la aplicación.

Rate Limiting es un escudo fundamental de seguridad sistémica. Mide la intensidad del tráfico por identificador (dirección IP, ID de sesión, clave API) y corta el tráfico excesivo en una etapa temprana del pipeline, garantizando la previsibilidad de la carga y la continuidad del servicio para usuarios legítimos.

2. Taxonomía arquitectónica y modelo mental

Elección arquitectónica de algoritmos y niveles de implementación de limitación de tráfico:

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMÍA ALGORÍTMICA DE RATE LIMITING      │
├─────────────────────────────────────────────────────────────┤
│ 1. Fixed Window: Contador simple con reinicio por minuto    │
│    (Vulnerable a picos de 2x tráfico en los bordes del intervalo) │
├─────────────────────────────────────────────────────────────┤
│ 2. Sliding Window Counter: Ventana deslizante híbrida       │
│    Weight = Prev_Count * (1 - Elapsed_Ratio) + Curr_Count   │
│    (Compromiso ideal: precisión + consumo mínimo de RAM)    │
├─────────────────────────────────────────────────────────────┤
│ 3. Token Bucket: Reabastecimiento de tokens a velocidad constante │
│    (Permite picos de tráfico legítimos hasta la capacidad del cubo) │
├─────────────────────────────────────────────────────────────┤
│ 4. Leaky Bucket: Velocidad constante de drenaje de la cola  │
│    (Óptimo para suavizar solicitudes salientes a la API)     │
└─────────────────────────────────────────────────────────────┘

1. Ventana deslizante híbrida (Sliding Window Counter):
   • Mantiene contadores para el intervalo de tiempo actual y anterior. En cada solicitud, calcula una suma ponderada basada en cuánto tiempo ha pasado en la ventana actual. Excluye anomalías en los bordes de los minutos.
2. Jerarquía de identificadores de cliente (Subject Identification):
   • Nivel Público: Dirección IP (para solicitudes anónimas y protección contra DDoS).
   • Nivel Autenticado: User_ID o Organization_ID (ignora redes NAT/VPN corporativas compartidas).
   • Nivel de Token: Cuotas granulares según el tipo de tarifa comprada (Free, Pro, Enterprise).
3. Backend distribuido de almacenamiento de estado (Redis Cluster / Upstash):
   • Almacenamiento centralizado en memoria rápida (In-Memory) que sincroniza contadores entre decenas de instancias de backend en microsegundos.

3. Pipeline técnico y mecánica interna

Ciclo de vida de verificación de solicitudes a través de Redis con un script Lua atómico:

1. Extracción de identificador y ruta: Middleware intercepta la solicitud entrante. Se forma una clave combinada: rate:auth:${req.ip} para el formulario de inicio de sesión o rate:llm:${user.id} para la ruta de IA.
2. Ejecución atómica del script Lua en Redis: Para evitar condiciones de carrera entre solicitudes paralelas, toda la lógica se empaqueta en un solo script Lua:
   • Se lee el timestamp actual.
   • Se eliminan registros más antiguos que el tamaño de la ventana deslizante (60 segundos).
   • Se calcula la cantidad de tokens activos.
3. Toma de decisiones:
   • Si el límite no se ha excedido: el contador se incrementa en 1 (o en el costo de la solicitud en tokens), se establece el TTL de la clave y la solicitud se pasa al controlador.
   • Si el límite se ha excedido: se genera una respuesta de rechazo.
4. Formación de encabezados HTTP estándar: El servidor devuelve al cliente los metadatos:

   HTTP/1.1 429 Too Many Requests
   Content-Type: application/json
   Retry-After: 24
   X-RateLimit-Limit: 10
   X-RateLimit-Remaining: 0
   X-RateLimit-Reset: 1718293840
   

5. Telemetría y alertas: El evento de exceder el límite se registra en el sistema de monitoreo; en caso de un pico anómalo desde una subred, se activa una regla de bloqueo en el firewall.

4. Escenarios prácticos de ingeniería en producción

01. Protección de rutas de IA generativas costosas (Token-Aware Limiting)

La ruta de generación de código descuenta tokens en proporción a la complejidad de la solicitud:

• En lugar de simplemente contar solicitudes, el rate limiter descuenta del saldo virtual del usuario la cantidad exacta de tokens generados.
• Los usuarios del plan gratuito tienen un límite de 50,000 tokens por día. Al agotarse el límite, la API bloquea la generación hasta el inicio del siguiente día.

02. Protección del formulario de autenticación contra fuerza bruta (Credential Defense)

Endpoint /api/auth/sign-in:

• Se permiten no más de 5 intentos fallidos de ingreso de contraseña en 15 minutos para una combinación de IP + Email.
• En el sexto intento, el sistema requiere pasar un captcha o envía un enlace para restablecer la contraseña por correo, neutralizando completamente los intentos de ataque por diccionario.

03. Suavizado del tráfico saliente hacia pasarelas de pago externas

Integración con Stripe, donde hay un límite de 100 solicitudes por segundo:

• Un microservicio interno utiliza una cola con el algoritmo Leaky Bucket.
• Incluso si los agentes internos de la empresa crean simultáneamente 500 pagos durante el Black Friday, la cola envía solicitudes a un flujo estrictamente uniforme (80 req/s), eliminando el riesgo de bloqueo de la cuenta de Stripe.

5. Errores comunes, trampas y seguridad

• Bloqueo de oficinas enteras debido a una limitación de tasa ingenua por IP: Si se aplica un límite estricto solo por IP a usuarios autorizados, un empleado activo de un centro de negocios bloqueará el acceso a todos sus colegas que acceden a Internet a través de una dirección NAT compartida de la empresa. Después de iniciar sesión, siempre limite por user_id.
• Condición de carrera al usar operaciones separadas GET y INCR: Si se verifica el límite con el comando GET, y luego se incrementa con INCR, un atacante puede enviar 100 solicitudes asíncronas simultáneas, y todas pasarán la verificación al mismo tiempo antes de que se actualice el contador. Utilice scripts atómicos.
• Desbordamiento de memoria en Redis al almacenar marcas de tiempo: El uso de listas desordenadas para almacenar marcas de cada solicitud sin establecer un TTL rígido rápidamente llena gigabytes de memoria RAM durante un ataque masivo.
• Ignorar encabezados de proxy (X-Forwarded-For Spoofing): Si su servidor está detrás de Cloudflare o Nginx y lee la IP directamente del socket, obtendrá la dirección local del proxy. Por otro lado, confiar ciegamente en el encabezado X-Forwarded-For no verificado permite a un atacante falsificar cualquier dirección IP.