n8n'de yüzlerce pasif workflow az kaynak tüketebilirken birkaç ağır workflow yoğun execution oluşturabilir. Güncel n8n dokümantasyonu en iyi ölçeklenebilirlik için queue mode'u öne çıkarır: main instance işleri Redis kuyruğuna bırakır, worker'lar execution'ları işler ve Postgres kalıcı veriyi tutar.
Queue mode execution yükünü main process'ten worker instance'lara dağıtır. Worker sayısı artırılıp azaltılarak yatay ölçek yapılabilir ve worker başına `--concurrency` ile aynı anda çalışacak job sayısı kontrol edilebilir. Queue mode için Redis ve desteklenen production database yapısı gerekir.
Main instance workflow yönetimi ve trigger/webhook tarafını koordine eder; job Redis queue'ya yazılır; worker execution'ı alır ve sonuç kalıcı database'e yansır.
HTTP request yapan kısa workflow ile büyük dosya işleyen Code node workflow aynı CPU/RAM süresini tüketmez.
n8n queue mode worker başına concurrency kontrolü sunar. CPU-heavy Code task ve IO-bound API workflow aynı concurrency ile verimli çalışmayabilir. Task runner kullanılıyorsa worker sidecar mimarisi ayrıca planlanmalıdır.
Container isimleri compose yapınıza göre değişebilir; main/worker/redis/postgres kaynak kullanımını ayrı gözlemleyin.
docker compose psdocker stats --no-streamdocker compose logs --tail=100 workerdocker compose logs --tail=100 n8nredis-cli PING 2>/dev/null || truepg_isready 2>/dev/null || trueGeçişte encryption key, database, binary data ve webhook URL tutarlılığı kritik olmalıdır.
Evet. Queue mode execution job'larını main ile worker'lar arasında Redis tabanlı queue üzerinden dağıtır.
Execution rate, ortalama duration, concurrency ve workload tipine göre belirlenmelidir. Sabit workflow sayısından çıkarılamaz.
Güncel n8n dokümantasyonu queue mode'un en iyi ölçeklenebilirliği sağladığını belirtir.
Dakikadaki execution, ortalama workflow süresi, binary payload, Code node ve webhook yoğunluğunu iletin; main/Redis/Postgres/worker topolojisini çıkaralım.