Rate Limiting en APIs Node.js con Redis y Sliding Window
· 13 min de lectura
Poner express-rate-limit en tu API no es rate limiting. Es teatro de seguridad. Si tu backend corre en dos o más instancias detrás de un load balancer, cada réplica cuenta requests por separado y tu "límite de 100 req/min" se convierte en 200, 400 o 1,000 según cuántos pods escales. El atacante no nota la diferencia. Tu base de datos sí.
El rate limiting serio vive fuera del proceso: en un almacén compartido que todas las réplicas consultan de forma atómica. Ese almacén, en la práctica, es Redis. Y el algoritmo correcto casi nunca es el contador fijo que viene por defecto en las librerías populares: es el sliding window log, que cuesta más en memoria pero no deja ventanas de abuse entre segundos.
En este artículo aprenderás:
- Por qué
express-rate-limitcon memoria local falla en arquitecturas con más de una instancia - Los tres algoritmos clásicos (fixed window, sliding window log, token bucket) explicados con sus trade-offs reales
- Implementación paso a paso de sliding window log con
ioredisy TypeScript, con operaciones atómicas - Cómo medir si funciona usando
autocannonpara simular ráfagas y ver cuándo se rompe - Checklist de producción con los errores que hemos visto en auditorías reales a APIs Node.js
