Rate limiting es una técnica que controla el número de requests que un cliente puede hacer a una API o servicio dentro de una ventana de tiempo especificada. Rate limiting protege servicios backend de sobrecarga, previene abuso, hace cumplir cuotas de uso, y asegura distribución justa de recursos entre consumidores.
Cómo funciona Rate Limiting
Rate limiting rastrea conteos de requests por identificador de cliente (API key, dirección IP, user ID) sobre ventanas de tiempo definidas. Cuando los conteos de requests exceden thresholds configurados, el sistema rechaza requests adicionales con respuestas de error (típicamente HTTP 429 Too Many Requests). Los clientes deben esperar hasta que la ventana de tiempo se resetee antes de hacer requests adicionales.
Algoritmos comunes de rate limiting incluyen fixed window (reset después de período de tiempo), sliding window (conteo smooth a través de períodos superpuestos), token bucket (tokens se reabastecen con el tiempo, requests consumen tokens), y leaky bucket (requests se encolan a tasa fija). Cada algoritmo balancea precisión, uso de memoria, y complejidad de implementación diferente.
Los rate limiters retornan headers HTTP indicando límites actuales, requests restantes, y tiempos de reset. Headers estándar incluyen X-RateLimit-Limit, X-RateLimit-Remaining, y X-RateLimit-Reset. Los clientes usan estos headers para implementar lógica de backoff y retry, ajustando tasas de request para mantenerse dentro de límites.
Cuándo usar Rate Limiting
Usa rate limiting cuando necesitas:
- Proteger APIs de abuso y ataques DDoS
- Hacer cumplir cuotas de uso de API y tiers de pricing
- Prevenir sobrecarga de servicios backend durante spikes de tráfico
- Asegurar asignación justa de recursos a través de usuarios
- Controlar costos de infraestructura por consumo de API
- Cumplir requerimientos regulatorios de disponibilidad de servicio
No uses rate limiting cuando necesitas:
- Servicios internos dentro de red confiable (usa circuit breakers en su lugar)
- Aplicaciones que requieren throughput garantizado de request
- Sistemas donde rechazo crea fallas críticas
- Protocolos sin soporte de rate limiting (conexiones WebSocket long-lived)
Señales que necesitas Rate Limiting
- Servicios backend fallando durante spikes de tráfico
- Abuso de API de actores maliciosos o clientes mal configurados
- Consumo de recursos desigual a través de usuarios
- Costos de infraestructura impredecibles por uso de API
- Degradación de rendimiento bajo carga concurrente alta
- Necesidad de tiers de pricing basados en uso
Métricas y medición
Métricas operativas:
- Tasa de trigger de rate limit: Porcentaje de requests rechazados por rate limiter (objetivo: menos de 5% para tráfico legítimo)
- Precisión de configuración de límites: Porcentaje de rate limits que matchean thresholds pretendidos
- Tasa de falsos positivos: Requests legítimos incorrectamente throttled (objetivo: menos de 1%)
- Manejo de bursts: Capacidad de manejar spikes de tráfico legítimo sin rechazo excesivo
Métricas de rendimiento:
- Overhead de rate limiting: Latencia agregada por revisión de rate (objetivo: menos de 1ms)
- Uso de memoria: Storage requerido para contadores de rate (depende de algoritmo y conteo de clientes)
- Throughput: Requests por segundo que el rate limiter puede procesar (objetivo: >10,000 req/s para deployments edge)
Métricas de negocio:
- Utilización de cuota: Porcentaje de usuarios acercándose a rate limits
- Distribución de tiers: Volumen de requests por tier de pricing
- Prevención de abuso: Tráfico malicioso bloqueado por rate limiting
Según datos de Cloudflare (2024), rate limiting configurado apropiadamente bloquea 80-95% de ataques DDoS volumétricos en edge de red. Rate limiting reduce carga backend 40-60% durante spikes de tráfico. APIs enterprise típicamente configuran 100-10,000 requests por minuto dependiendo del caso de uso.
Algoritmos de Rate Limiting
Fixed Window Counter
Algoritmo más simple. Contar requests en ventanas de tiempo fijas (e.g., por minuto). Resetear contador en boundary de ventana. Pros: simple, baja memoria. Contras: burst en boundaries de ventana, distribución desigual.
Sliding Window Log
Mantiene timestamps de requests recientes. Contar requests dentro de sliding time window. Pros: preciso, sin issues de boundary. Contras: alta memoria (almacenar timestamps), computación costosa.
Sliding Window Counter
Enfoque híbrido. Ponderar conteo de ventana previa basándose en progreso de ventana actual. Pros: limiting smooth, baja memoria. Contras: aproximado, slight edge cases.
Token Bucket
Tokens agregados a tasa fija hasta capacidad de bucket. Cada request consume un token. Requests rechazados cuando bucket vacío. Pros: maneja bursts, flexible. Contras: requiere mantenimiento de estado por cliente.
Leaky Bucket
Requests se encolan y drenan a tasa fija. Exceso de requests overflow (rechazados). Pros: tasa de output smooth. Contras: agrega latencia (tiempo de espera en cola), inflexible para bursts.
Casos de uso reales
Protección de API:
- Rate limiting de API pública por API key
- Límites basados en usuario para endpoints autenticados
- Límites basados en IP para acceso anónimo
- Límites específicos de endpoint para operaciones costosas
Mitigación de DDoS:
- Rate limiting de conexiones por IP
- Rate limiting de requests por endpoint
- Protección de burst para servidores origin
- Rate limiting geográfico para patrones de ataque
Enforcement de cuotas:
- Enforcement de tiers de pricing (free, pro, enterprise)
- Cuotas de uso mensuales por cliente
- Monetización de API pay-per-use
- Limitaciones de cuentas de trial
Protección de recursos:
- Rate limiting de queries de base de datos
- Throttling de cómputo costoso
- Limitación de calls a APIs de terceros
- Límites de operaciones de search y filtering
Equidad:
- Asignación de recursos multi-tenant
- Prevención de noisy neighbor
- Distribución igual de bandwidth
- Protección de infraestructura compartida
Errores comunes y soluciones
Error: Usar solo dirección IP para rate limiting Solución: IPs pueden ser spoofed o representar múltiples usuarios detrás de NAT. Usar API keys, user IDs, o combinación de identificadores. Rate limiting de tráfico autenticado y anónimo diferentemente.
Error: No comunicar límites a clientes Solución: Retornar headers de rate limit (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Incluir header Retry-After en respuestas 429. Documentar límites en documentación de API.
Error: Rate limiting sin guía de retry Solución: Incluir header Retry-After con tiempo de espera. Implementar exponential backoff en cliente. Proveer alternativas de webhook o polling para operaciones long-running.
Error: Límites fijos para todos los endpoints Solución: Diferentes endpoints tienen diferentes costos. Configurar límites más estrictos para operaciones costosas (search, AI inference). Permitir límites más altos para reads simples. Ponderar requests por costo computacional.
Error: No manejar rate limiting distribuido Solución: Rate limiters de instancia única fallan en sistemas distribuidos. Usar stores centralizados (Redis) o algoritmos distribuidos. Considerar tradeoffs de eventual consistency por rendimiento.
Error: Ignorar patrones de tráfico legítimo Solución: Configurar allowances de burst para spikes legítimos. Implementar límites diferentes para diferentes tiers de usuario. Monitorear patrones de tráfico y ajustar límites basándose en uso real.
Preguntas frecuentes
¿Qué código de status HTTP debe retornar rate limiting? HTTP 429 Too Many Requests es estándar para rate limiting. Incluir header Retry-After con tiempo de espera. El body de respuesta debe explicar límite excedido y proveer links de documentación.
¿Cómo manejo rate limiting en sistemas distribuidos? Usar data store centralizado (Redis, Memcached) para contadores compartidos. Considerar tradeoffs de eventual consistency. Alternativamente, usar enfoques basados en tokens con validación client-side y verificación server-side.
¿Debo rate limiting de usuarios autenticados y anónimos diferentemente? Sí. Usuarios autenticados típicamente obtienen límites más altos reflejando su tier. Usuarios anónimos (basados en IP) obtienen límites más estrictos previniendo abuso. Configurar límites separados para cada categoría.
¿Cómo prevengo que rate limiting bloquee tráfico legítimo? Implementar allowances de burst, rate limiting ponderado, y diferentes tiers. Monitorear tasas de falsos positivos. Proveer proceso fácil para usuarios legítimos de solicitar incrementos de límite.
¿Cuál es la diferencia entre rate limiting y throttling? Rate limiting rechaza requests que exceden threshold (límite hard). Throttling reduce velocidad de procesamiento para alcanzar targets de rate (límite soft). Rate limiting protege infraestructura; throttling maneja flujo.
¿Cómo calculo rate limits apropiados? Considerar capacidad backend, costo de request, patrones de comportamiento de usuario, y requerimientos de negocio. Empezar conservador, monitorear métricas, y ajustar basándose en uso real. Probar bajo carga para validar thresholds.
¿Puede rate limiting reemplazar protección DDoS? No. Rate limiting ayuda pero no puede detener ataques volumétricos a gran escala. Usar rate limiting para protección de application-layer y prevención de abuso. Combinar con mitigación DDoS dedicada para ataques de network-layer.
Cómo aplica en la práctica
Rate limiting es infraestructura API esencial que protege servicios backend y hace cumplir reglas de negocio. Las organizaciones implementan rate limiting en múltiples capas: CDN edge, API gateway, capa de aplicación.
Estrategia de implementación:
- Identificar puntos de rate limiting (edge, gateway, aplicación)
- Elegir algoritmos apropiados por capa
- Configurar límites por endpoint y tier de usuario
- Implementar respuestas de error y headers apropiados
- Monitorear métricas de rate limit y ajustar thresholds
- Proveer librerías cliente con lógica de backoff built-in
Decisiones de arquitectura:
- Desplegar rate limiting en edge para protección DDoS
- Usar API gateway para límites de application-level
- Implementar rate limiting distribuido para deployments multi-instancia
- Considerar sticky sessions para rate limiting basado en sesión
- Evaluar rate limiters centralizados vs. descentralizados
Integración de cliente:
- Documentar rate limits en documentación de API
- Proveer SDKs cliente con lógica de retry automática
- Implementar exponential backoff en respuestas 429
- Cachear respuestas para reducir API calls
- Monitorear headers de rate limit y ajustar patrones de request
Rate Limiting en Azion
Azion Firewall proporciona rate limiting en el edge:
- Rate limiting de requests por IP, API key, o identificador custom
- Deployment edge para revisión de rate de baja latencia antes de origin
- Thresholds configurables por endpoint y categoría de cliente
- Bloqueo automático con respuestas de error customizables
- Métricas en tiempo real monitoreando triggers de rate limit y patrones
- Integración con protección DDoS para defensa comprehensiva
La red distribuida de Azion hace cumplir rate limits globalmente, bloqueando tráfico malicioso antes de alcanzar infraestructura origin.
Conoce más sobre Azion Firewall, Protección DDoS, y API Security.
Fuentes:
- IETF. “RFC 6585: Additional HTTP Status Codes.” https://tools.ietf.org/html/rfc6585
- Kong. “API Rate Limiting Guide.” https://konghq.com/learning-center/api-rate-limiting