Limitierung der Anfragen Wie man vermeidet, von jeder API mit der Antwort 429 betroffen zu werden

Sie haben 429 erreicht. Ihr Skript hat die API für die letzten 60 Minuten intensiv belastet, Ihre Logs sind voller roter Einträge und die Bereitstellung dauert noch 20 Minuten. Damit wird das abstrakte jetzt konkret.

HTTP 429 Too Many Requests bedeutet, dass Sie mehr Anfragen gesendet haben als die Server in einem bestimmten Zeitfenster zulassen. Die korrekte Interpretation der Antwort und die korrekte Wiederholung sind Fähigkeiten, die die meisten Entwickler erst erlernen, nachdem sie bereits verbrannt wurden. Hier ist das vollständige Bild.

Was die 429 tatsächlich sagt

Der Statuscode ist nur die Hälfte der Nachricht. Die echte Information liegt in den Headers:

• Retry-After: 30 — Warten Sie 30 Sekunden, bevor Sie erneut versuchen. Kann auch ein HTTP-Date sein: Retry-After: Mon, 08 Jun 2026 15:00:00 GMT
• X-RateLimit-Limit: 100 — Gesamtanzahl der erlaubten Anfragen pro Fenster
• X-RateLimit-Remaining: 0 — Anfragen, die noch im aktuellen Fenster übrig sind (Sie sind bei null)
• X-RateLimit-Reset: 1749391200 — Unix-Timestamp, wann das Fenster neu beginnt

Nicht alle APIs senden alle diese Informationen. GitHub sendet die vollständige Menge. Stripe sendet Retry-After. Einige REST-APIs senden nichts und erwarten, dass Sie erraten. Wenn Sie Retry-After, verwenden Sie es genau — es ist die Serveranweisung, wie lange Sie sicher warten müssen. Wenn Sie es nicht tun, ist exponentielle Wiederholung Ihr Rückgrat.

Die falsche Wiederholung

Die naive Implementierung sieht so aus:

async function fetchWithoutBackoff(url) {
  while (true) {
    const res = await fetch(url);
    if (res.ok) return res;
    if (res.status === 429) continue; // immediately retry
  }
}

Dies ist aktiv schädlich. Wenn 10 Instanzen Ihres Dienstes gleichzeitig 429 erreichen und alle sofort erneut versuchen, landen alle Wiederholungen gleichzeitig — das Problem des „Sturms von Tieren“. Sie werden erneut rate-limitet, sofort, in einer engen Schleife, die unendlich laufen kann und Ihren Client so machen, als würde er absichtlich die API missbrauchen.

Exponentielle Wiederholung mit Rauschen

Das korrekte Muster: Jede Wiederholung wartet länger als die vorherige (exponentiell), und ein zufälliger Offset verhindert synchronisierte Wiederholungen bei mehreren Clients (Rauschen).

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  let attempt = 0;

  while (attempt <= maxRetries) {
    const res = await fetch(url, options);

    if (res.ok) return res;

    if (res.status !== 429) {
      throw new Error(`Request failed: ${res.status}`);
    }

    if (attempt === maxRetries) {
      throw new Error(`Rate limited after ${maxRetries} retries`);
    }

    // Use Retry-After if provided; otherwise exponential backoff + jitter
    const retryAfter = res.headers.get('Retry-After');
    let waitMs;

    if (retryAfter) {
      const seconds = isNaN(retryAfter)
        ? (new Date(retryAfter) - Date.now()) / 1000  // HTTP date
        : Number(retryAfter);                          // seconds
      waitMs = seconds * 1000;
    } else {
      const baseDelay = 1000 * Math.pow(2, attempt); // 1s, 2s, 4s, 8s, 16s
      const jitter = Math.random() * 1000;            // 0–1000ms random offset
      waitMs = baseDelay + jitter;
    }

    console.log(`Rate limited. Waiting ${Math.round(waitMs / 1000)}s (attempt ${attempt + 1}/${maxRetries})`);
    await new Promise(resolve => setTimeout(resolve, waitMs));
    attempt++;
  }
}

Die Rauschlinie ist der Teil, den die meisten Implementierungen verpassen. Ohne sie landen Wiederholungen von mehreren parallelen Prozessen immer noch in Clustern. Mit ihr werden sie über das Wartefenster verteilt.

Für APIs, die zurückgeben Retry-After, verwenden Sie diesen Wert als die Untergrenze — Wenn Sie nach dem spezifizierten Warten weiterhin 429 erhalten, wenden Sie exponentielle Wiederholung an.

Token-Bucket vs. Leaky-Bucket

Zwei Algorithmen dominieren die Implementierung von Rate-Limiters. Wenn Sie verstehen, welcher Algorithmus Sie verwenden, erfahren Sie viel über das Verhalten der API unter Druck — und welchen Algorithmus Sie bei der Entwicklung Ihrer eigenen wählen sollten.

Token-Bucket

Der Behälter enthält bis zu N Tokens. Jede Anfrage kostet 1 Token. Die Tokens füllen sich zu einer festen Rate (z. B. 10 pro Sekunde). Wenn der Behälter leer ist, wird die Anfrage abgelehnt oder in einer Warteschlange platziert.

Burst-freundlich. Wenn Sie eine Weile ohne Anfragen waren, haben Sie Tokens gesammelt und können einen Burst ohne das Limit auslösen. GitHubs API funktioniert so — 5.000 Anfragen pro Stunde, aber Sie können sie in einem einzigen Schritt nutzen, wenn Sie die API nicht lange verlassen haben. Gut für interaktive Anwendungsfälle mit sprunghaften Verkehr.

Leaky-Bucket

Anfragen gehen in eine Warteschlange und fließen aus zu einer festen Rate, unabhängig davon, wie schnell sie eintreffen. Wenn die Warteschlange voll ist, werden eingehende Anfragen abgelehnt.

Glatte Ausgabe, kein Burst. Auch wenn Sie noch Quoten haben, fließen die Anfragen zu der konfigurierten Rate. Der Nginx-Modul verwendet dies. Besser für die Schutz von untergeordneten Systemen vor Spitzen — nützlich für Webhook-Übertragungen, Ausgangs-API-Aufrufe und alles, was eine vorhersehbare Durchsatzrate bevorzugt. limit_req Welchen wählen Sie, wenn Sie Ihre eigene implementieren:

Benutzbare Endpunkte, die Burst-Toleranz benötigen → Token-Bucket. Ausgangswebhook-Übertragung oder Aufrufe von Drittanbietern → Leaky-Bucket. Hintergrundjobs, bei denen eine glatte Durchsatzrate wichtig ist → Leaky-Bucket. Berechnung sicherer Anfragenraten

Bevor Sie irgendwelche Wiederholungslogik schreiben, klären Sie, was Sie tatsächlich erlaubt ist. Wenn eine API sagt „1.000 Anfragen pro Stunde“, ist das 16,67 Anfragen pro Minute oder 0,278 Anfragen pro Sekunde. Fügen Sie einen Sicherheitspuffer von 20% hinzu und Sie sind bei etwa 13 Anfragen pro Minute — genügend Spielraum, um edge-case Timing-Probleme zu vermeiden, bei denen zwei Fenster sich überlappen.

Rate Limit Calculator

Verwenden Sie die Um Quoten-Zahlen in pro-Sekunde- und pro-Minute-Raten umzurechnen, das richtige Warteintervall zwischen Anfragen zu finden und zu sehen, wie Ihre Konkurrenzstufe das Risiko von Burst beeinflusst. Implementierung von Rate Limiting auf Ihrer eigenen API

Wenn Sie auf der anderen Seite sind und eine ordentliche 429-Verhaltensweise auf Ihrer eigenen API hinzufügen möchten:

Wählen Sie die richtige Granularität.

1. Per-IP ist einfach, aber funktioniert nicht bei Diensten hinter NAT oder gemeinsamen Ausgang. Per-API-Schlüssel ist besser, aber erfordert Authentifizierung. Per-User-ID ist ideal, wenn Sie diese haben. Vermeiden Sie die Kombination von Granularitäten, ohne zu wissen, welche davon gewinnt. Geben Sie immer
2. Auch ohne Retry-After. zwingt jedes Client, seine eigene Wiederholungsheuristik zu implementieren. Sie werden mehr „Sturm von Tieren“ bekommen, nicht weniger. Retry-After Verwenden Sie Redis für verteilte Rate Limiting.
3. In-Memory-Zähler funktionieren nicht über mehrere Serverinstanzen. Redis ist das Standardmuster. Bibliotheken wie INCR + EXPIRE rate-limiter-flexible (Node) und slowapi (Python/FastAPI) vereinfachen dies korrekt. Protokollieren Sie jede 429, die Sie auslösen.
4. Ein Sprung in 429s aus einem einzigen Schlüssel ist entweder ein Client-Fehler oder absichtliche Missbrauch. Beide sind wertvoll, um in Echtzeit zu erkennen. Rate-limiten Sie nicht bei Auth-Fehlern.
5. Geben Sie 401 für falsche Anmeldedaten zurück, nicht 429. Rate-limiten bei falschen Authentifizierungen ist die Art und Weise, wie Sie Ihre eigenen Benutzer bei einer Kennwortwechselphase versehentlich ausschalten. Was Sie jetzt richtig tun sollten

Wenn Sie 429 erreichen:

erst — verwenden Sie es, wenn es vorhanden ist, erfinden Sie keine eigene Verzögerung

• Prüfen Retry-After Implementieren Sie exponentielle Wiederholung mit Rauschen — der obige Code ist kopier- und einführbar
• Protokollieren Sie den
• Header bei jeder Antwort — Sie könnten schneller Quoten verbrauchen, als Sie denken X-RateLimit-Remaining Cache Antworten, bei denen die Daten nicht häufig wechseln
• Wenn Sie Rate Limiting implementieren: wählen Sie eine Redis-basierte Bibliothek, geben Sie

auf jede 429 zurück, überwachen Sie die 429-Rate pro Schlüssel und rate-limiten Sie nicht bei Auth-Fehlern. Retry-After Die 429 ist nicht das Problem — es ist die API, die Ihnen genau sagt, was schiefgelaufen ist und (normalerweise) wie lange Sie warten müssen. Die meisten Rate-Limit-Probleme entstehen daraus, dass man die Nachricht ignorieren und sofort wieder versuchen. Tun Sie das nicht.

Die 429 ist nicht das Problem — es ist die API, die dir genau erklärt, was schiefgelaufen ist und (meistens) wie lange du warten musst. Die meisten Probleme mit der Rate-Limitierung entstehen dadurch, dass die Meldung ignoriert wird und sofort erneut versucht wird. Das tun Sie nicht.

Das könnte Ihnen auch gefallen

Neu

GitHub Actions Secrets: How to Inject Config Without Hardcoding Anything Embarrassing

Mehr lesen "

Aktualisiert am Juni 23, 2026

Neu

Database Connection Pooling: Why Your App Crashes at 100 Users When Queries Take 10ms

Mehr lesen "

Aktualisiert am Juni 22, 2026

Neu

Git Interactive Rebase: Squash, Reorder, and Rewrite Commits Before They Hit main

Mehr lesen "

Aktualisiert am Juni 21, 2026

Neu

CORS erklärt: Warum funktioniert Ihr Fetch in curl, aber im Browser explodiert

Mehr lesen "

Aktualisiert am 20. Juni 2026