Rate limiting (restringir cuántas solicitudes/acciones se permiten en una ventana de tiempo) es un caso de uso común en Redis — los contadores atómicos rápidos de Redis y los TTLs lo hacen ideal. Existen varios algoritmos (ventana fija, ventana deslizante, token bucket), cada uno con compensaciones.
() {
key = ;
count = redis.(key);
(count === ) redis.(key, windowSec);
count <= limit;
}
El enfoque de ventana fija: un contador atómico por (usuario, ventana de tiempo) con un TTL — incrementar por solicitud, rechazar cuando se supera el límite. Simple y eficiente, aprovechando INCR atómico y auto-expiración.
✗ Limitation: bursts at window boundaries (2x limit possible across two adjacent windows)
SLIDING WINDOW → tracks requests over a rolling time period (no boundary bursts)
→ often uses a SORTED SET: add each request with a timestamp score,
remove old entries (ZREMRANGEBYSCORE), count remaining (ZCARD)
✓ More accurate/smooth ✗ More memory and complexity
TOKEN BUCKET → tokens refill at a steady rate; each request consumes a token
→ allows bursts (up to the bucket size) while limiting the average rate
→ often implemented with a Lua SCRIPT for atomic check-and-consume
✓ ATOMIC counters (INCR) → correct under concurrency, no race conditions
✓ Fast (in-memory) → minimal latency added to each request
✓ TTL → automatic window cleanup (no manual expiry management)
✓ SHARED across servers → distributed rate limiting (all app servers use one Redis)
→ Redis is the standard tool for distributed rate limiting.
Implementar rate limiting con Redis es un caso de uso común y práctico, así que comprenderlo es un conocimiento valioso — rate limiting (proteger APIs y servicios del abuso, garantizar un uso justo, prevenir sobrecarga) es una necesidad prácticamente universal, y Redis es la herramienta estándar para ello.
Comprender por qué Redis es ideal es clave: sus contadores atómicos (INCR) hacen que el conteo de tasas sea correcto bajo concurrencia (sin condiciones de carrera/pérdida de conteos), su velocidad (en memoria) añade latencia mínima a cada solicitud, los TTLs limpian automáticamente la ventana, y crucialmente es compartido entre servidores — permitiendo rate limiting distribuido donde todos los servidores de aplicación aplican un límite consistente (esencial en despliegues multi-servidor, donde los límites en memoria por servidor no funcionarían).
Comprender los algoritmos y sus compensaciones te permite elegir apropiadamente: ventana fija (más simple — un contador atómico por ventana de tiempo con un TTL, pero permitiendo ráfagas en los límites), ventana deslizante (más suave y precisa usando un conjunto ordenado de solicitudes con marca de tiempo, a mayor costo de memoria), y token bucket (permitiendo ráfagas controladas mientras se limita la tasa promedio, a menudo mediante un script Lua para atomicidad).
Saber cómo implementar estos (especialmente el patrón simple y común de ventana fija con INCR + EXPIRE) es una habilidad práctica y aplicable.
Dado que rate limiting es un requisito común para proteger servicios, y dado que Redis (con sus contadores atómicos, velocidad, TTLs y compartición entre servidores) es la herramienta estándar e ideal para rate limiting distribuido, comprender cómo implementarlo con Redis — los algoritmos, sus compensaciones, y por qué Redis se adapta tan bien — es conocimiento valioso y frecuentemente aplicable para construir servicios robustos y protegidos, una de las aplicaciones prácticas más comunes de Redis más allá del caché.