Rate limiting evita abuso y uso injusto. Implemente en la app (middleware) o en el borde (WAF, nginx). Use límites por IP o por clave; devuelva 429 y Retry-After. Las redes tier-III a menudo tienen protección DDoS aguas arriba.
Por qué rate limit
- Abuso: Bots y scrapers pueden sobrecargar su API o consumir cuota. Los rate limits acotan cuánto puede hacer un cliente.
- Uso justo: Asegura que un usuario pesado no deje sin servicio a los demás. Límites por usuario o clave permiten cuota y niveles.
- Coste y estabilidad: Reduce picos de tráfico inesperados y ayuda a dimensionar y presupuestar capacidad.
Dónde implementar
- Aplicación: Middleware o decorador que comprueba el número de peticiones por clave/IP y devuelve 429 cuando se supera el límite. Control total; puede usar Redis para límites distribuidos.
- Borde: Nginx limit_req, WAF o API gateway. Descarga la app; consistente en todos los endpoints. Combine con nivel de app para límites por usuario/clave.
- Proveedor: Algunos hosts ofrecen mitigación DDoS y rate limiting básico en el borde. Complementa límites de app/borde.
Cómo implementar
- Por IP: Simple; bueno para tráfico anónimo o no autenticado. Puede eludirse con muchas IPs (botnets).
- Por clave de API o usuario: Mejor para APIs autenticadas; ata el límite a la identidad. Use cuando tenga claves o sesiones.
- Ventana deslizante o fija: Cuente peticiones en una ventana de tiempo; deslizante es más justo. Devuelva 429 Too Many Requests y cabecera Retry-After para que los clientes hagan backoff.
Resumen
Rate limit en la app o en el borde; use por IP o por clave; devuelva 429 y Retry-After. Reduce abuso y asegura uso justo; combine con protección DDoS del proveedor para ataques volumétricos.
