Verarbeitung von Rate Limits über parallele Workflows hinweg ohne Durchsatzeinbußen

Hallo zusammen, ich habe ein etwas fortgeschritteneres Skalierungsproblem und könnte etwas Orientierung gebrauchen.
Ich habe mehrere Workflows, die parallel ausgeführt werden (ausgelöst durch Webhooks und Cron), die alle die gleiche externe API aufrufen, die strenge Rate Limits hat (z. B. 100 Anfragen pro Minute). Mit dem Wachstum der Nutzung bekomme ich immer häufiger 429-Fehler, und Wiederholungen verschärfen das Problem durch Lastspitzen.
Mein aktuelles Setup sieht so aus:
Webhook/Cron → Split In Batches → HTTP Request → Process
Momentan:
Jeder Workflow verwaltet seine eigenen Wiederholungen
Kein gemeinsames Bewusstsein für Rate Limits
Gelegentliche Lastspitzen überschreiten API-Limits
Beispiel-Wiederholungslogik:
if ($json.statusCode === 429) {
await new Promise(resolve => setTimeout(resolve, 1000));
return $input.all();
}
Das Problem:
Mehrere Workflows wiederholen zur gleichen Zeit → Thundering Herd Effect
Einen Workflow zu verlangsamen behebt nicht die anderen
Ich brauche eine globale Rate Limit-Kontrolle, nicht pro Workflow
Ich überlege:
Eine Queue zu nutzen (Redis / Bull)
API-Aufrufe in einem einzigen Workflow zu zentralisieren
Einen benutzerdefinierten Rate Limiter mit gemeinsamer State zu bauen

Beschreiben Sie das Problem/den Fehler/die Frage

Was ist das beste Muster in n8n, um globale Rate Limiting über mehrere Workflows hinweg zu handhaben und gleichzeitig einen guten Durchsatz zu bewahren?

Wie lautet die Fehlermeldung (falls vorhanden)?

Bitte teilen Sie Ihren Workflow

(Wählen Sie die Knoten auf Ihrer Canvas aus und verwenden Sie die Tastaturkürzel CMD+C/CTRL+C und CMD+V/CTRL+V zum Kopieren und Einfügen des Workflows.)

Geben Sie die Ausgabe des letzten Knotens aus

Informationen zu Ihrem n8n-Setup

  • n8n-Version:
  • Datenbank (Standard: SQLite):
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main):
  • n8n wird ausgeführt über (Docker, npm, n8n cloud, Desktop-App):
  • Betriebssystem:

Hi @Roseline Du läufst in ein klassisches Rate-Limit-Problem und dein aktuelles Setup (Pro-Workflow-Wiederholungen) wird immer zu Spitzen führen. Jeder Workflow agiert unabhängig, daher finden Wiederholungen zur gleichen Zeit statt → 429-Storms.

Versuche, die API-Aufrufe zu zentralisieren

Statt dass jeder Workflow die API aufruft:

Alle Workflows → Queue → Single Worker → HTTP Request → Process

Du kannst einen „API-Worker

Danke für die Vorschläge, ich sehe, dass es ein globales Ratenlimit ist

Danke für die Vorschläge @Niffzy

Der zentralisierte Workflow-Ansatz ist definitiv die sauberste Lösung. Eine Sache, die du zu diesem Pattern hinzufügen solltest: Verwende einen Wait-Node mit einer berechneten Verzögerung statt einer festen.

Wenn deine API 100 Anfragen/Minute erlaubt, kannst du die Verzögerung pro Anfrage als (60 / 100) * 1000 = 600ms berechnen. Dann wartet jeder Aufruf des zentralen Dispatchers einfach 600ms, bevor er weitergeleitet wird. Kein Thundering Herd, kein gemeinsamer Redis-Status erforderlich, und der Durchsatz bleibt vorhersehbar.

Für noch mehr Ausfallsicherheit kannst du auch das “Circuit Breaker”-Pattern hinzufügen - wenn du 3 aufeinanderfolgende 429-Fehler erhältst, stelle das Senden für volle 60 Sekunden ein, bevor du weitermachst. Das schützt dich bei unerwarteten Bursts.

Hoffe, das hilft!

– Nguyen Thieu Toan (Jay Nguyen) - n8n Verified Creator