Was sind API-Rate-Limiting und Throttling?

Rate-Limiting ist eine Kontrolle, die deckelt, wie viele Anfragen ein Client pro Fenster stellen darf; Throttling bremst den Überschuss, statt ihn abzulehnen. Nehmen Sie den dritten Verwandten hinzu – die Quota (das Kontingent), eine Zuteilung pro Abrechnungszeitraum – und Sie haben das vollständige Vokabular, das die meisten Erklärungen zu einem einzigen Wort verschmelzen. Zusammen sorgen die drei dafür, dass APIs fair, rentabel und erreichbar bleiben.

Das Wichtigste in Kürze

Was die 429-Antwort und die Rate-Limit-Header bedeuten

HTTP/1.1 429 Too Many Requests        ← RFC 6585
Retry-After: 30                       ← so lange warten (Sekunden oder Datum)
X-RateLimit-Limit: 1000               ← Ihr Budget in diesem Fenster
X-RateLimit-Remaining: 0              ← was davon übrig ist
X-RateLimit-Reset: 1767024000         ← wann es sich auffüllt
RateLimit: "default";r=0;t=30         ← die entstehende IETF-Standardform

Die Client-Hälfte des Vertrags – der Code, den jeder SDK-Nutzer irgendwann braucht:

// JavaScript / Node.js — Back4app JS SDK
// The client half of rate limiting: back off, with jitter, then retry
async function withBackoff(fn, attempt = 0) {
  try {
    return await fn();
  } catch (e) {
    if (e.code !== 155 || attempt >= 4) throw e;   // 155: request limit hit
    const wait = 2 ** attempt * 500 + Math.random() * 200;
    await new Promise((r) => setTimeout(r, wait)); // exponential + jitter
    return withBackoff(fn, attempt + 1);
  }
}
const results = await withBackoff(() => query.find());

// Flutter / Dart — Back4app Flutter SDK
// The client half of rate limiting: back off, with jitter, then retry
Future<ParseResponse> withBackoff(Future<ParseResponse> Function() fn,
    [int attempt = 0]) async {
  final response = await fn();
  if (response.success || attempt >= 4) return response;
  final wait = (1 << attempt) * 500 + Random().nextInt(200);
  await Future.delayed(Duration(milliseconds: wait)); // exponential + jitter
  return withBackoff(fn, attempt + 1);
}
final response = await withBackoff(() => query.query());

// iOS / Swift — Back4app Swift SDK
// The client half of rate limiting: back off, with jitter, then retry
func withBackoff<T>(_ attempt: Int = 0,
                    _ fn: @escaping () async throws -> T) async throws -> T {
  do { return try await fn() }
  catch {
    guard attempt < 4 else { throw error }
    let wait = pow(2.0, Double(attempt)) * 0.5 + .random(in: 0...0.2)
    try await Task.sleep(for: .seconds(wait))   // exponential + jitter
    return try await withBackoff(attempt + 1, fn)
  }
}
let results = try await withBackoff { try await query.find() }

// Android / Kotlin — Back4app Android SDK
// The client half of rate limiting: back off, with jitter, then retry
suspend fun <T> withBackoff(attempt: Int = 0, fn: suspend () -> T): T {
  return try {
    fn()
  } catch (e: ParseException) {
    if (attempt >= 4) throw e
    val wait = (1L shl attempt) * 500 + Random.nextLong(200)
    delay(wait)                                 // exponential + jitter
    withBackoff(attempt + 1, fn)
  }
}
val results = withBackoff { query.find() }

Token Bucket vs. Leaky Bucket vs. festes Fenster vs. gleitendes Fenster

Eine verteilte Fußnote, die die Diagramme auslassen: Bei vielen API-Servern muss der Bucket an einem gemeinsamen Ort leben – typischerweise in einem In-Memory-Store, der atomare Inkremente ausführt – und Sie wählen zwischen strenger Genauigkeit (jede Prüfung geht an den Store) und Geschwindigkeit (lokale Zähler, lockere Synchronisation). Die meisten Plattformen akzeptieren leicht lockere Limits als Preis für die Latenz; vertraglich zugesicherte Quotas bekommen die strenge Behandlung.

Geltungsbereich: Wer genau wird begrenzt?

Pro IP stoppt anonyme Fluten und Sickerverluste bei der DDoS-Absorption, aber ein Büro-NAT macht aus Hunderten Benutzern eine einzige Adresse. Pro Schlüssel bindet Limits an Anwendungen und Preismodelle – der Geltungsbereich, der die eigentliche Arbeit leistet. Pro Benutzer hindert ein Konto daran, den Schlüssel einer geteilten App zu monopolisieren. Pro Endpoint bepreist teure Operationen ehrlich – Such- und Export-Endpoints verdienen engere Budgets als Health Checks. Produktivsysteme schichten sie übereinander; die zusammengesetzte Frage lautet immer: “Welches Budget hat diese Anfrage verbraucht?”

Typische Anwendungsfälle

• Schutz öffentlicher APIs – der kanonische Fall: faire Budgets pro Schlüssel, in Headern veröffentlicht, an der Grenze durchgesetzt.
• Durchsetzung von Tarifstufen – kostenlose gegenüber bezahlten Tarifen, die sich genau in Quota und Burst-Spielraum unterscheiden.
• Abwehr von Missbrauch und Scraping – enge Limits für Anonyme, großzügige für Authentifizierte.
• Kostenkontrolle auf teuren Pfaden – LLM-Aufrufe, Exporte, Suchen: Budgets pro Endpoint, die die tatsächlichen Kosten abbilden.
• Selbstverteidigung auf Client-Seite – Backoff und Zusammenfassen von Anfragen gegenüber den Limits anderer, die Ihre Integrationen respektieren müssen, um nicht gesperrt zu werden.

Ablehnen oder throtteln? Eine Entscheidungsmatrix

Und die Meta-Regel: Was immer Sie wählen, veröffentlichen Sie es – Limits in der Dokumentation und in Headern verwandeln eine frustrierende Mauer in einen technischen Vertrag, auf dem Clients aufbauen können.

Grenzen und Trade-offs

• Limits sind grobe Werkzeuge. Eine Anfrage ist keine Kosteneinheit – ein billiger Lesezugriff und ein monströser Export verbrauchen beide “1”. Kostenbewusstes Limitieren (Punkte pro Operation) ist die Verfeinerung, zum Preis der Komplexität.
• Verteilte Genauigkeit kostet Latenz. Strenge globale Zähler serialisieren sich auf einem gemeinsamen Store; lockere lokale lassen am Rand zu viel durch. Wählen Sie nach der Garantie, nicht nach der Mode.
• 429er bestrafen die unschuldige Wiederholungsschleife. Clients ohne Jitter synchronisieren sich zu Thundering Herds; das Design Ihres Limiters muss den schlimmsten Client annehmen, denn er wird ihm begegnen.
• Throttling verbirgt Überlastung. Eingereihte Anfragen glätten die Diagramme und bauen dabei unsichtbaren Rückstau auf; Queues brauchen Obergrenzen und Verwerfungsregeln, sonst werden sie zu aufgeschobenen Ausfällen.
• Limits sind Produktentscheidungen im Ops-Gewand. Budgets, Tarifstufen und Burst-Spielräume prägen Nutzererlebnis und Umsatz – legen Sie sie mit geöffneter Preisseite fest, nicht nur mit dem Dashboard.

Rate-Limiting mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Schutz ist hier eine Voreinstellung der Plattform und kein Projekt: Anfragelimits greifen an der Grenze, pro App und pro Tarif, teure Operationen lassen sich hinter Cloud-Code-Funktionen mit eigenen Prüfungen legen, und Clients erhalten saubere 429-Semantik – die das Backoff-Muster auf SDK-Seite aus den Code-Tabs oben in widerstandsfähiges Verhalten statt fehlgeschlagener Bildschirme verwandelt. Sie stellen Richtlinien ein; den Limiter bauen Sie nicht.