Den richtigen Rate-Limiting-Algorithmus auswählen
Vergleichen Sie die grundlegenden Rate-Limiting-Algorithmen – Fixed Window, Sliding Window, Token Bucket und Leaky Bucket – und lernen Sie, wann welcher zu Ihrem Traffic-Profil und Ihren Fairness-Zielen passt.
Den richtigen Rate-Limiting-Algorithmus auswählen ist eine kostenlose API Rate Limiting & Scalability Patterns-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des API Rate Limiting & Scalability Patterns-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der API Rate Limiting & Scalability Patterns-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
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.
Lerne API Rate Limiting & Scalability Patterns mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 12
- Lektionen
- 48
Häufig gestellte Fragen
Ist die Lektion „Den richtigen Rate-Limiting-Algorithmus auswählen“ kostenlos?
Ja — der vollständige Text von „Den richtigen Rate-Limiting-Algorithmus auswählen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des API Rate Limiting & Scalability Patterns-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der API Rate Limiting & Scalability Patterns-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Den richtigen Rate-Limiting-Algorithmus auswählen“?
Vergleichen Sie die grundlegenden Rate-Limiting-Algorithmen – Fixed Window, Sliding Window, Token Bucket und Leaky Bucket – und lernen Sie, wann welcher zu Ihrem Traffic-Profil und Ihren Fairness-Zie… Du übst API Rate Limiting & Scalability Patterns mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um API Rate Limiting & Scalability Patterns zu starten?
Keine Vorkenntnisse erforderlich. API Rate Limiting & Scalability Patterns auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Den richtigen Rate-Limiting-Algorithmus auswählen“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser API Rate Limiting & Scalability Patterns-Lektion Code schreiben und ausführen?
Ja. Jede API Rate Limiting & Scalability Patterns-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Throttling und Ratenbegrenzung erklärt
- Richtlinien für Bursts und Kulanzzeiträume
- Limits auf Client- und Serverseite
- Den richtigen Rate-Limiting-Algorithmus auswählen