API-Leistung: Ratenbegrenzung, Paginierung und asynchrone Verarbeitung

Ihre API ist unter Spitzenlast nur so schnell wie ihr langsamster Endpunkt. Ein einzelner nicht optimierter Endpunkt, der Datenbankverbindungen 5 Sekunden lang hält, kann Ihren Verbindungspool erschöpfen und Ausfälle auf Ihrer gesamten Plattform kaskadieren. Das API-Performance-Engineering konzentriert sich auf drei Säulen: Schutz Ihrer API vor Überlastung (Ratenbegrenzung), effiziente Verarbeitung großer Datenmengen (Paginierung) und Verlagerung kostspieliger Vorgänge aus dem Anforderungszyklus (asynchrone Verarbeitung).

Wichtige Erkenntnisse

• Token Bucket und Sliding Window sind die beiden ratenbegrenzenden Algorithmen, die 95 % der Anwendungsfälle abdecken – wählen Sie je nachdem, ob Sie Burst-Toleranz oder strikte Durchsetzung wünschen – Die Cursor-basierte Paginierung übertrifft die Offset-Paginierung bei großen Datensätzen, da sie das Zählen übersprungener Zeilen vermeidet – Die asynchrone Verarbeitung mit Jobwarteschlangen reduziert die P95-Antwortzeiten, indem der E-Mail-Versand, die PDF-Generierung und die Webhook-Zustellung aus dem Anforderungspfad verlagert werden – Die Antwortkomprimierung mit Brotli reduziert die Nutzlastgröße um 70–85 %, was sich direkt in einem schnelleren clientseitigen Rendering niederschlägt

---

Ratenbegrenzungsalgorithmen

Die Ratenbegrenzung schützt Ihre API vor Missbrauch, sorgt für eine faire Ressourcenzuteilung und verhindert kaskadierende Ausfälle bei Datenverkehrsspitzen. Der von Ihnen gewählte Algorithmus bestimmt, wie mit Bursts umgegangen wird und wie vorhersehbar das begrenzende Verhalten für Verbraucher ist.

Token-Bucket

Der Token-Bucket-Algorithmus ist für die meisten APIs die praktischste Wahl. Ein Bucket fasst Token bis zu einer maximalen Kapazität. Token werden zu einem festen Preis (der Nachfüllrate) hinzugefügt. Jede Anfrage verbraucht ein Token. Wenn der Bucket leer ist, wird die Anfrage abgelehnt oder in die Warteschlange gestellt.

Der Hauptvorteil des Token-Buckets ist die Burst-Toleranz. Wenn ein Client eine Zeit lang keine Anfragen gestellt hat, ist sein Bucket voll und er kann eine Flut von Anfragen stellen, bis die Bucket-Kapazität erreicht ist. Dies entspricht natürlichen Nutzungsmustern – ein Client, der ein Dashboard lädt, stellt möglicherweise 20 Anfragen schnell hintereinander und dann 30 Sekunden lang nichts.

Konfigurationsbeispiel für eine E-Commerce-API:

• Eimergröße: 100 Token
• Nachfüllrate: 10 Token pro Sekunde – Dies ermöglicht Bursts von bis zu 100 Anfragen, während langfristig 10 Anfragen pro Sekunde aufrechterhalten werden

Schiebefenstertheke

Der Schiebefensterzähler kombiniert die Präzision eines Schiebefensterblocks mit der Speichereffizienz eines festen Fensters. Es verwaltet Zähler für das aktuelle und das vorherige Fenster und berechnet dann eine gewichtete Anzahl basierend darauf, wie weit die Anforderung im aktuellen Fenster liegt.

Für ein 60-Sekunden-Fenster, das nach 45 Sekunden ausgewertet wird, beträgt die effektive Anzahl: (Anzahl des vorherigen Fensters * 0,25) + (Anzahl des aktuellen Fensters). Dadurch wird das Boundary-Burst-Problem fester Fenster beseitigt, ohne dass individuelle Anforderungszeitstempel gespeichert werden müssen.

Implementierung mit Redis

Redis ist der Standard-Backup-Speicher für verteilte Ratenbegrenzung, da es atomare Inkrementierungsoperationen mit TTL bereitstellt. Verwenden Sie INCR mit EXPIRE für feste Fenster oder sortierte Sätze mit ZADD und ZRANGEBYSCORE für Schiebefenster. Für den Token-Bucket stellen Redis Lua-Skripte atomare Prüf- und Dekrementierungsvorgänge bereit.

Rate-Limiting-Header kommunizieren Limits an API-Konsumenten:

• X-RateLimit-Limit – maximal zulässige Anfragen im Fenster
• X-RateLimit-Remaining – Anfragen, die im aktuellen Fenster verbleiben
• X-RateLimit-Reset – Unix-Zeitstempel, wenn das Fenster zurückgesetzt wird
• Retry-After – Sekunden, bis der Client es erneut versuchen sollte (bei 429 Antworten)

---

Paginierungsstrategien

Jeder Listenendpunkt muss paginiert sein. Die Rückgabe unbegrenzter Ergebnismengen verschwendet Bandbreite, belastet die Datenbank und birgt das Risiko von Zeitüberschreitungsfehlern, wenn die Datenmenge wächst.

Versetzte Paginierung

Bei der versetzten Paginierung werden die SQL-Klauseln LIMIT und OFFSET verwendet. Der Client fordert ?page=3&limit=20 an und der Server übersetzt in OFFSET 40 LIMIT 20.

Vorteile:

• Einfach umzusetzen und zu verstehen
• Kunden können direkt zu jeder Seite springen – Die Gesamtzahl aktiviert die Benutzeroberfläche „Seite X von Y“.

Nachteile: – Die Leistung nimmt bei hohen Offsets ab – OFFSET 1000000 scannt immer noch 1.000.000 Zeilen, bevor Ergebnisse zurückgegeben werden

• Inkonsistente Ergebnisse, wenn sich Daten zwischen Seiten ändern (Zeilen verschieben sich, wenn neue Daten eingefügt oder gelöscht werden) – Die Abfrage der Gesamtanzahl (COUNT(*)) kann bei großen Tabellen teuer sein

Cursorbasierte Paginierung

Bei der Cursor-basierten Paginierung wird ein undurchsichtiger Cursor (normalerweise ein codierter Primärschlüssel oder Zeitstempel) verwendet, um die Position im Ergebnissatz zu markieren. Der Client fordert ?cursor=abc123&limit=20 an und der Server verwendet den Cursor als WHERE-Klausel: WHERE id > decoded(abc123) LIMIT 20.

Vorteile:

• Konsistente Leistung unabhängig von der Position im Datensatz – kein versetztes Scannen
• Stabile Ergebnisse, auch wenn sich Daten zwischen den Seiten ändern
• Natürliche Passform für unendliches Scrollen und Echtzeit-Feeds

Nachteile:

• Es kann nicht zu beliebigen Seiten gesprungen werden (kein „Gehe zu Seite 50“)
• Komplexer in der Umsetzung, insbesondere bei mehrspaltigen Sortierreihenfolgen
• Die Gesamtzahl muss bei Bedarf separat angegeben werden

Welche Paginierung verwendet werden soll

Paginierungsantwortformat

Eine gut gestaltete Paginierungsantwort enthält Metadaten, die Kunden zum Navigieren benötigen:

{
  "data": [],
  "pagination": {
    "total": 15432,
    "limit": 20,
    "hasMore": true,
    "nextCursor": "eyJpZCI6MTAwfQ=="
  }
}

---

Asynchrone Verarbeitung mit Jobwarteschlangen

Synchrone API-Endpunkte sollten innerhalb von 200 ms Antworten zurückgeben. Jeder Vorgang, der länger dauert – E-Mails senden, PDFs erstellen, Bilder verarbeiten, externe APIs aufrufen, Berichte ausführen – sollte in eine Hintergrundjobwarteschlange verschoben werden.

Das Job-Warteschlangenmuster

1. Der API-Endpunkt validiert die Anfrage und erstellt einen Jobdatensatz
2. Der Job wird in eine Warteschlange gestellt (Redis, RabbitMQ, SQS)
3. Die API kehrt sofort mit der Antwort „202 Accepted“ und einer Job-ID zurück
4. Ein Arbeitsprozess holt den Job ab und führt ihn asynchron aus
5. Der Client fragt den Auftragsstatus ab oder erhält nach Abschluss einen Webhook-Rückruf

Häufige Async-Anwendungsfälle

E-Mail-Versand – SMTP-Vorgänge dauern je nach Anbieter 500 ms bis 3 s. Das Einreihen von E-Mails in die Warteschlange verkürzt die API-Antwortzeit und ermöglicht eine Wiederholungslogik für vorübergehende Fehler, ohne den Benutzer zu blockieren.

PDF-Generierung – Das Generieren von Rechnungen, Berichten oder Exportdateien ist CPU-intensiv und speicherintensiv. Wenn Sie diese in dedizierten Workern ausführen, wird ein Ressourcenkonflikt bei der Bearbeitung von API-Anfragen verhindert.

Webhook-Bereitstellung – Ausgehende Webhooks hängen von der Serververfügbarkeit des Drittanbieters ab. Stellen Sie Webhook-Zustellungen mit exponentiellen Backoff-Wiederholungsversuchen (1 Sek., 2 Sek., 4 Sek., 8 Sek., bis zu 5 Minuten) in die Warteschlange, um vorübergehende Fehler zu bewältigen, ohne Ihr System zu blockieren.

Datenimport und -export – Die Verarbeitung von CSV-Uploads mit 100.000 Zeilen sollte niemals in einem Anforderungszyklus erfolgen. Akzeptieren Sie den Upload, geben Sie eine Job-ID zurück und verarbeiten Sie Zeilen stapelweise.

Warteschlangenauswahl

---

Antwortoptimierung

Über die Anwendungslogik hinaus kann die Antwort selbst hinsichtlich Größe und Liefergeschwindigkeit optimiert werden.

Komprimierung

Aktivieren Sie die Antwortkomprimierung, um die Nutzlastgröße im Netzwerk zu reduzieren. Moderne Komprimierungsalgorithmen reduzieren die textbasierten Nutzdaten (JSON, HTML, CSS, JavaScript) erheblich.

Verwenden Sie Brotli für statische Assets (zur Erstellungszeit vorkomprimiert) und gzip als Fallback für dynamische Antworten. In NestJS übernimmt die Komprimierungs-Middleware dies automatisch, aber in der Produktion überlassen Sie Nginx die Komprimierung, um die CPU von Ihrem Anwendungsserver zu entlasten.

Feldauswahl

Ermöglichen Sie API-Konsumenten, nur die Felder anzufordern, die sie benötigen. GraphQL erledigt dies von Natur aus, aber REST-APIs können die Feldauswahl mit einem ?fields=id,name,price-Abfrageparameter unterstützen. Dies reduziert die Nutzlastgröße und kann Datenbankabfragen optimieren, indem nur benötigte Spalten ausgewählt werden.

Antwort-Caching-Header

Legen Sie geeignete Cache-Control-Header für API-Antworten fest. Endpunkte öffentlicher Listen (Produkte, Kategorien) können Cache-Control: public, max-age=300 zum Zwischenspeichern für 5 Minuten verwenden. Authentifizierte Endpunkte sollten Cache-Control: private, no-cache verwenden, um CDN-Caching zu verhindern und gleichzeitig Browser-Caching mit erneuter Validierung zu ermöglichen.

Weitere Informationen zu Caching-Strategien finden Sie in unserem ausführlichen Leitfaden zu Redis-, CDN- und HTTP-Caching.

---

Verbindungsverwaltung

Datenbank- und HTTP-Verbindungen sind endliche Ressourcen, die unter Last sorgfältig verwaltet werden müssen.

Datenbankverbindungspooling

Ein Verbindungspool verwaltet eine Reihe wiederverwendbarer Datenbankverbindungen. Ohne Pooling öffnet jede API-Anfrage eine neue Datenbankverbindung (50–100 ms Overhead) und schließt sie nach der Antwort. Beim Pooling leihen Anforderungen Verbindungen aus dem Pool aus und geben sie zurück, wenn sie fertig sind.

Pool-Größenformel: Verbindungen = (Kernanzahl * 2) + effektive_Spindelanzahl. Für einen 4-Core-Server mit SSD-Speicher sind 10–20 Verbindungen pro Anwendungsinstanz ein guter Ausgangspunkt. Überwachen Sie die Poolauslastung – wenn sie regelmäßig 80 % überschreitet, erhöhen Sie entweder die Poolgröße oder optimieren Sie die Abfragedauer.

HTTP Keep-Alive

Aktivieren Sie HTTP-Keep-Alive für Verbindungen zu Upstream-Diensten (Datenbanken, Redis, externe APIs). Dadurch werden TCP-Verbindungen wiederverwendet, anstatt pro Anfrage neue aufzubauen, wodurch der TCP-Handshake und der TLS-Verhandlungsaufwand (50–200 ms pro neue Verbindung) entfallen.

---

Häufig gestellte Fragen

Welche Ratenlimits sollte ich für eine öffentliche API festlegen?

Beginnen Sie mit konservativen Grenzwerten und passen Sie sie basierend auf legitimen Nutzungsmustern an. Ein üblicher Ausgangspunkt sind 100 Anfragen pro Minute für authentifizierte Benutzer und 20 Anfragen pro Minute für anonyme Benutzer. Überwachen Sie die 429-Antwortraten – wenn legitime Benutzer häufig an Grenzen stoßen, erhöhen Sie diese. Bieten Sie höhere Limits für Premium-API-Stufen.

Wie gehe ich mit der Paginierung um, wenn sich Daten zwischen Seiten ändern?

Die Cursor-basierte Paginierung bewältigt dies auf natürliche Weise, da sie an einer bestimmten Position in den sortierten Daten verankert wird. Dokumentieren Sie bei versetzter Paginierung, dass sich die Ergebnisse zwischen den Seiten verschieben können. Erstellen Sie für kritische Anwendungsfälle (Finanzberichte, Datenexporte) einen Snapshot der Daten zu Beginn der Paginierung und paginieren Sie über den Snapshot.

Sollte ich REST oder GraphQL für die Leistung verwenden?

REST mit Feldauswahl und ordnungsgemäßem Caching ist für einfache, klar definierte Endpunkte schneller. GraphQL eliminiert Over-Fetching und Under-Fetching bei komplexen Datenanforderungen, erhöht jedoch den Aufwand für das Parsen von Abfragen und erschwert das HTTP-Caching. Verwenden Sie REST für öffentliche APIs mit Caching-Anforderungen und GraphQL für interne APIs, die komplexe Frontend-Datenanforderungen erfüllen.

Wie überwache ich die API-Leistung in der Produktion?

Verfolgen Sie die Antwortzeiten P50, P95 und P99 pro Endpunkt. Legen Sie Warnungen fest, wenn P95 Ihr SLO verletzt (normalerweise 200–500 ms). Verwenden Sie die verteilte Ablaufverfolgung, um die für Datenbank, Cache, externe Dienste und Anwendungslogik aufgewendete Zeit aufzuschlüsseln. Ausführliche Informationen zur Einrichtung finden Sie in unserem Leitfaden zu Überwachung und Beobachtbarkeit.

---

Was kommt als nächstes?

Überprüfen Sie zunächst Ihre API-Endpunkte auf fehlende Paginierung, ungeschützte öffentliche Endpunkte ohne Ratenbegrenzung und synchrone Vorgänge, die asynchron sein sollten. Diese drei Änderungen verkürzen die P95-Reaktionszeiten in der Regel um 50–70 % und verhindern die häufigsten Produktionsvorfälle.

Die vollständige Performance-Engineering-Perspektive finden Sie in unserem Säulenleitfaden zur Skalierung Ihrer Geschäftsplattform. Informationen zur Datenbankebene, die Ihre API unterstützt, finden Sie in unserem Leitfaden zur Abfrageoptimierung.

ECOSIRE erstellt leistungsstarke APIs für Geschäftsplattformen auf Odoo ERP und benutzerdefinierten Architekturen. Kontaktieren Sie uns für eine API-Leistungsüberprüfung.

---

Veröffentlicht von ECOSIRE – Unterstützung von Unternehmen bei der Skalierung mit KI-gestützten Lösungen in Odoo ERP, Shopify eCommerce und OpenClaw AI.