So beheben Sie '429 Too Many Requests' in Ihrer Web-App

Ihre Web-App funktioniert plötzlich nicht mehr. API-Aufrufe schlagen fehl. Benutzer sehen Fehlermeldungen. Der Übeltäter? HTTP 429 Too Many Requests – die Art und Weise, wie der Server Ihrer Anwendung mitteilt, dass sie langsamer werden soll.

Dieser Leitfaden erklärt, was 429-Fehler in modernen Webanwendungen verursacht, wie Sie die Signale interpretieren, die Server senden, und praktische Strategien für Frontend-Request-Throttling, die diese Fehler verhindern.

Was HTTP 429 Too Many Requests tatsächlich bedeutet

Der Statuscode 429 zeigt an, dass Ihr Client die vom Server festgelegten Rate Limits überschritten hat. Im Gegensatz zu 500er-Fehlern (Serverprobleme) oder 503 Service Unavailable (temporäre Überlastung) ist ein 429 eindeutig: Sie stellen zu viele Anfragen, und der Server schützt sich selbst.

API-Rate-Limiting kann aus mehreren Quellen stammen:

• Ihr eigenes Backend, das Limits pro Benutzer oder pro Session durchsetzt
• CDNs und WAFs, die Verkehrsmuster blockieren, die missbräuchlich aussehen
• Drittanbieter-APIs, die ihre Infrastruktur vor übermäßigen Aufrufen schützen

Jede Quelle kann unterschiedliche Limits, unterschiedliche Erkennungsfenster und unterschiedliche Wiederherstellungsverhalten haben. Eine einzelne Benutzeraktion in Ihrer App kann Anfragen an mehrere Dienste auslösen, von denen jeder einen 429 zurückgeben könnte.

Rate-Limit-Header verstehen

Wenn Server Rate-Limiting implementieren, kommunizieren sie Limits oft über Response-Header. Es existieren zwei Muster:

Legacy-Header verwenden das Präfix X-RateLimit-*:

• X-RateLimit-Limit: Maximal erlaubte Anfragen
• X-RateLimit-Remaining: Verbleibende Anfragen im aktuellen Zeitfenster
• X-RateLimit-Reset: Wann das Limit zurückgesetzt wird (normalerweise Unix-Timestamp)

Standardisierte Header folgen dem neueren Format RateLimit und RateLimit-Policy, das ähnliche Informationen mit besser definierten Semantiken bereitstellt.

Nicht jede API verwendet diese Header. Einige geben nur den 429-Status ohne zusätzlichen Kontext zurück. Ihr Code sollte beide Szenarien handhaben.

Der Retry-After-Header

Der Retry-After-Header teilt Clients mit, wann sie sicher wiederholen können. Er erscheint in zwei Formaten:

Retry-After: 120                            // Sekunden zu warten
Retry-After: Wed, 21 Oct 2025 07:28:00 GMT  // spezifischer Zeitstempel

Wenn vorhanden, respektieren Sie ihn. Wenn nicht vorhanden, implementieren Sie exponentielles Backoff – warten Sie progressiv länger zwischen Wiederholungsversuchen (1 Sekunde, dann 2, dann 4 und so weiter).

Einige Server lassen Retry-After vollständig weg. Andere fügen ihn inkonsistent hinzu. Bauen Sie Ihre Retry-Logik so auf, dass sie ohne ihn funktioniert, ihn aber berücksichtigt, wenn er verfügbar ist.

Frontend-Request-Throttling-Strategien

Die meisten 429-Fehler in frontend-lastigen Anwendungen entstehen durch UI-Interaktionen, die übermäßige API-Aufrufe auslösen. So verhindern Sie sie:

Debouncing bei Benutzereingaben

Suchfelder, Autocomplete-Felder und Filter lösen oft bei jedem Tastendruck Anfragen aus. Debouncing wartet, bis der Benutzer aufhört zu tippen, bevor die Anfrage gesendet wird:

function debounce(func, delay) {
  let timeoutId;
  return function (...args) {
    clearTimeout(timeoutId);
    timeoutId = setTimeout(() => func.apply(this, args), delay);
  };
}

// 300ms nach dem letzten Tastendruck warten, bevor gesucht wird
const debouncedSearch = debounce(searchAPI, 300);

Verwandte Anfragen bündeln

Anstatt Daten für jedes Element einzeln abzurufen, kombinieren Sie Anfragen, wo APIs dies unterstützen. Eine Anfrage für 50 Elemente ist besser als 50 einzelne Anfragen.

Aggressives Caching

Speichern Sie Antworten, die sich nicht häufig ändern. Bevor Sie eine Anfrage stellen, prüfen Sie, ob Sie bereits gültige gecachte Daten haben. Dies gilt sowohl für Browser-Caches als auch für Caching auf Anwendungsebene.

Rate-Limit-Signale respektieren

Wenn Sie Rate-Limit-Header erhalten, nutzen Sie diese proaktiv. Wenn X-RateLimit-Remaining zeigt, dass Sie fast erschöpft sind, verlangsamen Sie, bevor Sie die Grenze erreichen.

429-Fehler elegant behandeln

Wenn trotz Präventionsmaßnahmen ein 429 auftritt:

1. Parsen Sie die Response nach Retry-After oder Rate-Limit-Headern
2. Reihen Sie die fehlgeschlagene Anfrage zur Wiederholung nach der angegebenen Verzögerung ein
3. Informieren Sie Benutzer angemessen – zeigen Sie einen Ladezustand, keinen Fehler
4. Protokollieren Sie das Auftreten, um Muster in Ihrem Monitoring zu identifizieren

Vermeiden Sie sofortige Wiederholungsversuche. Einen Server zu bombardieren, der Ihnen gerade gesagt hat, Sie sollen langsamer werden, verschlimmert die Situation und kann längere Blockierungen auslösen.

Beachten Sie, dass einige CDNs und WAFs feste Cooldown-Zeitfenster durchsetzen, was bedeutet, dass Wiederholungsversuche unabhängig von der clientseitigen Backoff-Logik minutenlang blockiert werden können.

429 von anderen Fehlern unterscheiden

Ein 429 erfordert Warten. Ein 503 könnte sich schnell auflösen oder auf einen größeren Ausfall hinweisen. Ein 500 deutet auf einen Bug hin. Ihre Fehlerbehandlung sollte differenzieren:

• 429: Zurückziehen, warten, mit der angegebenen Verzögerung wiederholen
• 503: Mit Backoff wiederholen, aber auf längere Ausfälle überwachen
• 500: Fehler protokollieren, möglicherweise einmal wiederholen, dann elegant scheitern

Fazit

HTTP 429 Too Many Requests ist ein Rate-Limiting-Signal, kein Fehler. Verhindern Sie es durch Frontend-Request-Throttling – Debouncing, Batching und Caching. Wenn es passiert, respektieren Sie den Retry-After-Header und implementieren Sie exponentielles Backoff.

Die beste Lösung für 429-Fehler ist, sie nie auszulösen. Entwerfen Sie Ihre Anwendung so, dass sie nur notwendige Anfragen stellt, und Sie werden diesen Fehler in der Produktion selten sehen.

FAQs

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.