Hallo zusammen,
ich betreibe eine Multi-Tenant-n8n-Plattform, bei der sich jeder Tenant mit externen APIs mit unterschiedlichen Rate Limits verbindet.
Die Herausforderung besteht darin, dass einige Tenants sehr niedrige Limits haben, während andere viel höhere Kontingente haben.
Aktuelle Konfiguration: Webhook → Queue → Worker → External API
Probleme, die ich sehe:
• Einige Tenants stoßen viel schneller an Rate Limits als andere
• Wiederholungsversuche erzeugen Datenverkehrsspitzen
• Ein beschäftigter Tenant kann einen großen Teil der Worker-Kapazität verbrauchen
• Es ist schwierig, faire Nutzung über Tenants hinweg durchzusetzen
Ich erwäge:
• Queues pro Tenant
• Token-Bucket- / Leaky-Bucket-Rate-Limiting
• Redis-Counters
• Dedizierte Worker für Tenants mit hohem Volumen
Für Teams, die Multi-Tenant-Automationen im großen Maßstab betreiben:
• Wie erzwingt ihr Rate Limits pro Tenant?
• Isoliert ihr Queues nach Tenant oder nutzt ihr eine gemeinsame Queue mit Drosselung?
• Gibt es empfohlene Muster, um zu verhindern, dass ein Tenant andere beeinflusst, während man gleichzeitig einen guten Durchsatz beibehält?
Problem/Fehler/Frage beschreiben
Wie lautet die Fehlermeldung (falls vorhanden)?
Bitte teilt euren Workflow
(Wählt die Knoten auf eurer Leinwand aus und nutzt die Tastaturkürzel CMD+C/STRG+C und CMD+V/STRG+V zum Kopieren und Einfügen des Workflows.)
Hi @Decoure_Ryan ein üblicher Ansatz ist die Verwendung von Pro-Mandant-Ratenbegrenzung statt einer globalen Limitierung.
Webhook → Queue → Rate Limit Check → Worker → API
Verfolgung von Anfragen pro Mandant mit Redis oder einer Datenbank und Verarbeitung von Jobs nur, wenn dieser Mandant innerhalb seines zulässigen Limits liegt.
Das hilft dabei, dass ein Mandant andere nicht beeinflusst
Verschiedene API-Limits pro Mandant werden bearbeitet
Spitzen durch Wiederholungen werden reduziert
Für Mandanten mit hohem Volumen: Separate Queues
Dedizierte Worker, damit ihr Traffic nicht alle anderen beeinflusst.
Willkommen @Decoure_Ryan in unserer Community! Ich bin Jay und bin ein verifizierter n8n Creator.
Der praktischste n8n-spezifische Ansatz hier ist, einen Code-Knoten vor jedem externen API-Aufruf zu verwenden, um einen Zähler pro Mandant zu prüfen und zu aktualisieren. Wenn du Redis verwendest, speichere den Schlüssel als rate_limit:{tenantId} mit einem Verfallsfenster, das dem Reset-Zeitraum der API entspricht – erhöhe ihn bei jeder Anfrage, und wenn der Mandant das Limit überschritten hat, leite zu einem Wait-Knoten weiter, anstatt fortzufahren.
Für das Retry-Burst-Problem: Anstatt n8n’s eingebauten Retry (der sofort ausgelöst wird und 429er verstärken kann), fange die Fehlerausgabe vom HTTP Request-Knoten ab und leite sie an einen Wait-Knoten mit einer fixen oder dynamischen Verzögerung weiter, die aus dem Retry-After Response-Header gezogen wird, dann schleife zurück zur Anfrage.
Wenn du im Queue-Modus bist, geben dir Pro-Workflow-Concurrency-Limits natürliche Pro-Mandant-Isolierung, wenn die Jobs jedes Mandanten in einem dedizierten Sub-Workflow laufen – setze concurrency: 1 pro Mandant-Workflow und die Queue kümmert sich um die Drosselung für dich, ohne irgendwelche Redis-Zähler-Logik.
Hier sind einige Dinge, die sich in großem Maßstab bewährt haben:
Die Warteschlangen pro Mandant sind die richtige Wahl. Gemeinsame Warteschlangen mit Drosselung klingen zunächst einfach, führen aber regelmäßig zu Problemen durch störende Nachbarn. Eine isolierte Warteschlange bietet echte Isolation ohne komplexe Prioritätslogik.
Bei der Token-Bucket-Implementierung ist Redis solid – speichern Sie einfach einen Schlüssel pro Mandant mit TTL-basierter Nachfüllung. Wiederholungsversuche sollten nicht alle auf einmal nach dem Zurücksetzen des Rate-Limit-Fensters abgefeuert werden – verwenden Sie exponentielles Backoff mit Jitter.
Was die Worker-Zuteilung betrifft: Erwägen Sie ein gestuftes Modell mit einem kleinen Pool dedizierter Worker für die Mandanten mit dem höchsten Volumen und gemeinsamen Workern für alle anderen. Dies vermeidet Überbereitstellung und schützt dennoch den Durchsatz der Top-Mandanten.
Etwas, das oft übersehen wird: Instrumentieren Sie die Warteschlangentiefe und Wartezeit pro Mandant, nicht nur die Rate-Limit-Treffer. Hier finden Sie normalerweise den eigentlichen Engpass, bevor es zu einem SLA-Problem kommt.
Welche Art von externen APIs rufen Sie auf? Einige haben Burst-Zulassungen, die das Wiederholungsproblem erheblich entschärfen können.
Der Ansatz mit einem Token-Bucket pro Tenant in Redis ist die richtige Intuition, und die entscheidende Designwahl ist, das Limit durchzusetzen, bevor der Job den Worker erreicht, nicht darin. Wenn der Worker einen Job zieht und dann auf ein Ratenlimit wartet, bindest du Worker-Kapazität, die nichts tut – genau dein Problem „ein beschäftigter Tenant frisst die Kapazität aller auf