Elección del algoritmo adecuado de limitación de frecuencia
Compare los principales algoritmos de limitación de frecuencia —ventana fija, ventana deslizante, token bucket y leaky bucket— y aprenda cuándo encaja cada uno con su perfil de tráfico y sus objetivos de equidad.
Elección del algoritmo adecuado de limitación de frecuencia es una lección gratuita de API Rate Limiting & Scalability Patterns en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de API Rate Limiting & Scalability Patterns, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de API Rate Limiting & Scalability Patterns incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
Why the Algorithm Matters
A rate limit policy is only as good as the algorithm that enforces it. The same limit of 100 requests/minute behaves very differently depending on how you count.
In this lesson we compare four classic approaches and learn how to pick one based on your fairness, burst, and accuracy needs.
Fixed Window Counter
The simplest approach: count requests in a fixed time window (for example each calendar minute) and reset the counter at the boundary.
- Pros: trivial to implement, low memory
- Cons: allows a burst of
2xthe limit around the window edge
def allow(counter, limit):
if counter['count'] >= limit:
return False
counter['count'] += 1
return TrueThe Boundary Burst Problem
With a fixed window, a client can send limit requests at 00:59 and another limit at 01:00. That is double the intended rate in a one-second span.
Sliding window algorithms exist to smooth out exactly this spike.
Sliding Window Log
Store a timestamp for every request. To decide, drop timestamps older than the window and count what remains.
- Pros: exact, no boundary burst
- Cons: memory grows with request volume
def allow(log, now, window, limit):
cutoff = now - window
log[:] = [t for t in log if t > cutoff]
if len(log) >= limit:
return False
log.append(now)
return TrueSliding Window Counter
A hybrid: keep the current and previous fixed-window counts, then estimate the rate using a weighted overlap.
It approximates the sliding log with far less memory, which is why API gateways and CDNs favor it.
weighted = prev_count * overlap + curr_count
allowed = weighted < limitToken Bucket
A bucket holds tokens up to a capacity. Tokens refill at a steady rate; each request spends one token. Empty bucket means reject.
- Allows controlled bursts up to the bucket capacity
- Smooths the long-term average to the refill rate
def allow(bucket, now, rate, capacity):
elapsed = now - bucket['ts']
bucket['tokens'] = min(capacity, bucket['tokens'] + elapsed * rate)
bucket['ts'] = now
if bucket['tokens'] < 1:
return False
bucket['tokens'] -= 1
return TrueLeaky Bucket
Requests enter a queue that leaks at a constant rate. If the queue overflows, requests are dropped.
Unlike the token bucket, the leaky bucket enforces a steady output rate — ideal when a downstream service cannot handle spikes.
Token vs. Leaky Bucket
- Token bucket lets traffic burst up to capacity, then throttles — good for user-facing APIs that should feel responsive.
- Leaky bucket forces a smooth, constant flow — good for protecting fragile backends.
Memory and Accuracy Trade-offs
Pick based on constraints:
- Lowest memory: fixed window
- Highest accuracy: sliding window log
- Best balance: sliding window counter
- Burst-friendly: token bucket
Distributed Considerations
Across many servers, each node cannot keep its own counter or you multiply the real limit. Use a shared store like Redis with atomic operations so the count is global.
Token bucket and sliding window counter both map cleanly to Redis primitives.
-- Redis atomic counter with expiry
INCR rate:user:42
EXPIRE rate:user:42 60A Decision Checklist
Ask:
- Do I need to allow short bursts? → token bucket
- Must downstream see a steady rate? → leaky bucket
- Is exactness critical for billing? → sliding window log
- Do I want simple and cheap? → fixed or sliding window counter
Quick Check
Test your understanding of algorithm selection.
Recap
You compared four rate limiting algorithms:
- Fixed window — cheap but allows edge bursts
- Sliding window — accurate, smooths boundaries
- Token bucket — burst-friendly, averages out
- Leaky bucket — constant output rate
Choose based on burst tolerance, accuracy, and memory budget.
Preguntas frecuentes
¿La lección «Elección del algoritmo adecuado de limitación de frecuencia» es gratis?
Sí — el texto completo de «Elección del algoritmo adecuado de limitación de frecuencia» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de API Rate Limiting & Scalability Patterns, actualiza a CoddyKit PRO. El curso de API Rate Limiting & Scalability Patterns incluye 4 lecciones en total.
¿Qué aprenderé en «Elección del algoritmo adecuado de limitación de frecuencia»?
Compare los principales algoritmos de limitación de frecuencia —ventana fija, ventana deslizante, token bucket y leaky bucket— y aprenda cuándo encaja cada uno con su perfil de tráfico y sus objetivo… Practicas API Rate Limiting & Scalability Patterns con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar API Rate Limiting & Scalability Patterns?
No se requiere experiencia previa. API Rate Limiting & Scalability Patterns en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Elección del algoritmo adecuado de limitación de frecuencia»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de API Rate Limiting & Scalability Patterns?
Sí. Cada lección de API Rate Limiting & Scalability Patterns incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Explicación de throttling y limitación de tasa
- Políticas de ráfagas y periodos de gracia
- Límites en el cliente frente al servidor
- Elección del algoritmo adecuado de limitación de frecuencia