Algoritmos de Rate Limiting | Token Bucket, Leaky Bucket y Sliding Window Explicados

Los algoritmos de rate limiting son los mecanismos que hacen cumplir cuántas solicitudes puede hacer un cliente dentro de una ventana de tiempo definida. El algoritmo que elijas determina cómo se maneja el tráfico en ráfagas, con qué equidad se aplican los límites y con qué precisión se mide la ventana.

TL;DR Los cuatro principales algoritmos de rate limiting son: fixed window counter (simple pero vulnerable a ráfagas de borde), sliding window log (preciso pero con uso intensivo de memoria), sliding window counter (buen equilibrio entre precisión y eficiencia), token bucket (permite ráfagas controladas) y leaky bucket (suaviza la salida a una tasa constante). Token bucket es el más común para rate limiting de API porque permite ráfagas cortas mientras sigue aplicando una tasa promedio. Leaky bucket es preferido cuando la tasa de salida consistente importa más que permitir ráfagas.

Por qué importan los algoritmos de rate limiting

El rate limiting sin un algoritmo bien elegido crea dos modos de fallo comunes:

1. El problema de la ráfaga de borde — Una ventana fija ingenua permite 2× la tasa prevista en los límites de ventana. Si el límite es 100 req/min, un cliente puede enviar 100 solicitudes a las 11:59:59 y 100 más a las 12:00:00 — 200 solicitudes en 2 segundos.
2. Tráfico en ráfagas vs. tráfico suave — Algunos casos de uso requieren salida suave y consistente (procesamiento de pagos, escrituras en base de datos). Otros legítimamente necesitan ráfagas cortas (cargas de página que disparan múltiples llamadas a la API simultáneamente). El algoritmo incorrecto penaliza a usuarios legítimos o falla en proteger el backend.

Fixed window counter

Cómo funciona: Divide el tiempo en ventanas fijas (ej.: intervalos de 1 minuto). Cuenta las solicitudes por cliente en la ventana actual. Si el recuento supera el límite, rechaza las solicitudes hasta que comience la siguiente ventana.

Ventana: 12:00:00 – 12:00:59
Límite: 100 solicitudes

Cliente envía 80 solicitudes a las 12:00:05 → permitido (recuento: 80)
Cliente envía 30 más a las 12:00:45 → rechazado (el recuento sería 110)
La ventana se reinicia a las 12:01:00 → el cliente puede enviar 100 de nuevo

El problema de la ráfaga de borde:

Ventana 1: 12:00:00 – 12:00:59 → 100 solicitudes a las 12:00:55 ✓
Ventana 2: 12:01:00 – 12:01:59 → 100 solicitudes a las 12:01:05 ✓
Resultado: 200 solicitudes en 10 segundos — 2× la tasa prevista

Pros: Simple de implementar, bajo uso de memoria (un contador por cliente por ventana). Contras: Permite hasta 2× de ráfaga en los límites de ventana.

Sliding window log

Cómo funciona: Almacena una marca de tiempo para cada solicitud. Cuando llega una nueva solicitud, cuenta cuántas solicitudes ocurrieron en los últimos N segundos (la ventana deslizante). Si el recuento está por debajo del límite, permite la solicitud y agrega la marca de tiempo.

Límite: 5 solicitudes por 60 segundos
Hora actual: 12:05:30

Marcas de tiempo almacenadas: [12:04:40, 12:05:00, 12:05:10, 12:05:20, 12:05:25]
Recuento en los últimos 60s: 5 → rechazar nueva solicitud

Pros: Perfectamente preciso — sin problema de ráfaga de borde. Contras: Uso intensivo de memoria (almacena cada marca de tiempo de solicitud). Para 1M de usuarios a 100 req/min, eso son 100M de entradas de marca de tiempo.

Sliding window counter

Cómo funciona: Una aproximación práctica del sliding window log. Mantiene contadores para las ventanas fijas actual y anterior, luego estima el recuento en la ventana deslizante usando el recuento de la ventana anterior ponderado por cuánto de esa ventana se superpone con la ventana deslizante actual.

Límite: 100 req/min
Recuento de ventana anterior: 80
Recuento de ventana actual: 30
Posición actual: 75% a través de la ventana actual (45 segundos adentro)

Recuento estimado = (80 × 0.25) + 30 = 20 + 30 = 50 → permitir solicitud

Pros: Bajo uso de memoria (dos contadores por cliente), suficientemente preciso para la mayoría de los casos de uso, sin problema de ráfaga de borde. Contras: Aproximado — puede ocasionalmente permitir un poco más que el límite.

Token bucket

Cómo funciona: Cada cliente tiene un bucket con una capacidad máxima de N tokens. Los tokens se agregan a una tasa fija (tasa de recarga). Cada solicitud consume un token. Si el bucket está vacío, la solicitud se rechaza o se pone en cola.

Capacidad del bucket: 20 tokens
Tasa de recarga: 10 tokens/segundo

El cliente no hace nada durante 2 segundos → el bucket se llena a 20 tokens
El cliente envía 15 solicitudes instantáneamente → el bucket tiene 5 tokens (ráfaga permitida)
El cliente envía 6 más → rechazado (solo quedan 5 tokens)
Después de 0.1 segundos → 1 nuevo token → puede enviar 1 solicitud más

Propiedad clave: Permite ráfagas hasta la capacidad del bucket, mientras aplica la tasa promedio de recarga con el tiempo. Un cliente que ha estado inactivo puede acumular tokens y gastarlos en una ráfaga — esto modela el comportamiento legítimo del usuario (carga de página que dispara múltiples llamadas a la API).

Pros: Permite ráfagas controladas, conceptualmente simple, ampliamente usado. Contras: Dos parámetros para ajustar (capacidad y tasa de recarga). Los clientes pueden “ahorrar” grandes ráfagas si han estado inactivos.

Leaky bucket

Cómo funciona: Las solicitudes van a una cola (el bucket). Se procesan a una tasa constante — la tasa de “filtración”. Si la cola está llena, las nuevas solicitudes se rechazan.

Tasa de filtración: 10 solicitudes/segundo
Capacidad de la cola: 50 solicitudes

100 solicitudes llegan a la vez:
→ 50 entran en la cola (capacidad llena)
→ 50 son rechazadas
→ La cola se vacía a 10 req/seg → tarda 5 segundos en vaciarse

Propiedad clave: La salida siempre es suave y constante, independientemente de la naturaleza en ráfagas de la entrada. Las solicitudes nunca se procesan más rápido que la tasa de filtración.

Pros: Garantiza una tasa de salida consistente, evita la sobrecarga del backend por tráfico en ráfagas. Contras: No permite ninguna ráfaga — incluso las ráfagas cortas y legítimas se ponen en cola o se rechazan. Mayor latencia durante las ráfagas (las solicitudes esperan en la cola). Menos intuitivo para los límites de tasa de API por usuario.

Comparando los algoritmos

Rate limiting distribuido

El rate limiting en servidor único es sencillo — los contadores viven en memoria. En sistemas distribuidos (múltiples instancias de gateway de API), el contador debe compartirse:

• Almacenamiento centralizado (Redis) — Todas las instancias incrementan el mismo contador en Redis. Las operaciones atómicas INCR + EXPIRE garantizan consistencia. ~1ms de sobrecarga por solicitud.
• Aproximación local — Cada instancia rastrea un contador local y periódicamente sincroniza con un almacenamiento central. Menos preciso pero menor latencia.
• Hashing consistente — Enruta cada cliente a la misma instancia basándose en el ID del cliente. Evita el estado compartido pero reduce la flexibilidad del balanceo de carga.

El rate limiting basado en Redis es el enfoque de producción más común: INCR key, verifica contra el límite, establece EXPIRE si es la primera solicitud en la ventana.

Preguntas frecuentes

¿Cuál es el algoritmo de rate limiting más común? Token bucket es el más ampliamente usado para rate limiting de API porque permite ráfagas cortas y legítimas (como una carga de página que dispara 5 llamadas a la API simultáneamente) mientras sigue aplicando una tasa promedio. La mayoría de los gateways de API y productos de rate limiting en la nube usan token bucket o sliding window counter.

¿Cuál es la diferencia entre token bucket y leaky bucket? Token bucket permite ráfagas — los clientes pueden acumular tokens cuando están inactivos y gastarlos rápidamente. Leaky bucket produce una tasa de salida constante independientemente de los patrones de entrada — las solicitudes se ponen en cola y se procesan a una tasa fija, sin ráfagas permitidas. Token bucket es mejor para APIs donde las ráfagas son legítimas. Leaky bucket es mejor para la protección del backend donde se requiere un throughput constante.

¿Qué es el problema de la ráfaga de borde en el rate limiting de ventana fija? Una ventana fija se reinicia completamente en el límite de la ventana. Un cliente puede enviar el máximo de solicitudes permitidas al final de una ventana y el máximo permitido al comienzo de la siguiente — efectivamente enviando 2× la tasa prevista en una ráfaga corta. Los algoritmos de ventana deslizante eliminan este problema.

¿Cómo implemento rate limiting en un sistema distribuido? Usa un contador atómico compartido en Redis u otro caché distribuido. El patrón estándar de Redis: INCR <clave> (incrementa el contador), luego verifica si excede el límite, y establece EXPIRE <clave> <segundos_de_ventana> si esta es la primera solicitud (para crear la ventana de tiempo). Esto maneja correctamente las solicitudes concurrentes usando las operaciones atómicas de Redis.

¿Qué código de estado HTTP devuelve el rate limiting? 429 Too Many Requests es el código de estado estándar para las respuestas de rate limiting. Incluye un header Retry-After que indica cuándo puede hacer otra solicitud el cliente. Muchas APIs también incluyen los headers X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset para ayudar a los clientes a gestionar sus tasas de solicitud.

¿Cuál es la diferencia entre rate limiting y throttling? El rate limiting aplica un límite estricto — las solicitudes por encima del límite se rechazan. El throttling ralentiza las solicitudes — las solicitudes en exceso se ponen en cola y se retrasan en lugar de rechazarse. El rate limiting es más simple y predecible. El throttling mantiene más solicitudes vivas pero puede aumentar la latencia durante alta carga.

¿Deben aplicarse los límites de tasa por IP o por usuario? Ambos. Los límites por IP protegen contra ataques de fuentes únicas. Los límites por usuario aplican políticas de uso justo para clientes autenticados. Solo por IP es ineficaz contra ataques distribuidos usando muchas IPs. Solo por usuario no protege los endpoints no autenticados. Un enfoque en capas aplica ambos.

¿Cómo elijo entre sliding window y token bucket? Usa sliding window counter cuando necesites aplicar un límite estricto de solicitudes por período de tiempo (ej.: “100 solicitudes por minuto”) sin ninguna asignación de ráfaga. Usa token bucket cuando los clientes necesiten legítimamente ráfagas (ej.: “ráfaga de 20, luego sostener 10/segundo”) — como cargas de página que disparan múltiples llamadas a la API simultáneamente.