n8n Worker Yapısı Büyüyünce Hangi Sunucu Gerekir?

n8n iş akışları birkaç otomasyondan yüzlerce paralel göreve çıktığında, tek bir sunucuda çalışan basit kurulumlar hızla darboğaza girebilir. Özellikle queue mode, worker sayısı, Redis, veritabanı performansı ve işlem yoğunluğu birlikte değerlendirilmeden yapılan kapasite artışları; gecikme, bekleyen job birikmesi ve beklenmeyen kesintilerle sonuçlanabilir.

n8n worker mimarisinde sunucu ihtiyacı nasıl değişir?

n8n’de worker yapısı büyüdükçe asıl mesele yalnızca daha fazla CPU veya RAM eklemek değildir. İş yükünün türü, workflow’ların ne kadar sık tetiklendiği, her bir görevin ne kadar süre çalıştığı ve harici servislerden gelen yanıt süreleri kapasite planlamasını doğrudan etkiler.

Bu nedenle n8n worker sunucu seçimi yapılırken önce sistemin hangi tip iş yükünü taşıdığı analiz edilmelidir. Hafif API çağrıları yapan akışlar ile büyük veri işleyen, dosya dönüştüren veya uzun süreli entegrasyonlar çalıştıran akışların ihtiyaçları aynı değildir.

Küçük, orta ve yoğun kullanım için temel kaynak önerileri

Küçük ölçekli worker yapısı

Günde birkaç yüz workflow çalıştıran, çoğunlukla kısa süreli API entegrasyonları kullanan yapılarda 2-4 vCPU, 4-8 GB RAM ve SSD disk çoğu zaman yeterli olur. Bu seviyede n8n ana uygulaması, Redis ve PostgreSQL aynı sunucuda çalışabilir; ancak düzenli yedekleme ve izleme mutlaka yapılandırılmalıdır.

Orta ölçekli worker yapısı

Paralel çalışan işlerin arttığı, kuyrukta bekleyen görevlerin oluşmaya başladığı yapılarda en sağlıklı yaklaşım bileşenleri ayırmaktır. n8n main instance, Redis, PostgreSQL ve worker süreçlerinin ayrı sunucularda veya ayrı container kaynak limitleriyle çalışması önerilir. Bu senaryoda worker sunucuları için 4-8 vCPU ve 8-16 GB RAM makul bir başlangıçtır.

Yoğun ve kritik iş yükleri

Dakikada çok sayıda tetikleme alan, webhook yoğunluğu yüksek veya müşteri süreçlerini doğrudan etkileyen yapılarda yatay ölçekleme gerekir. Birden fazla worker node, ayrı yönetilen PostgreSQL, ayrı Redis ve yük dengeleyici kullanımı operasyonel güvenilirliği artırır. Bu noktada tek büyük sunucu yerine, izlenebilir ve gerektiğinde genişletilebilir bir mimari daha doğru olur.

Karar verirken bakılması gereken metrikler

Sunucu büyütme kararı tahminle değil, ölçümle verilmelidir. CPU kullanımı sürekli yüzde 70’in üzerindeyse, RAM swap kullanmaya başladıysa veya kuyrukta bekleyen job sayısı düzenli artıyorsa kapasite yetersizliği oluşuyor olabilir.

İzlenmesi gereken temel metrikler şunlardır:

• Ortalama workflow çalışma süresi
• Kuyrukta bekleyen job sayısı
• Worker başına eş zamanlı işlem sayısı
• PostgreSQL bağlantı sayısı ve sorgu süreleri
• Redis bellek kullanımı ve gecikme değerleri
• Webhook yanıt süreleri

Bu metrikler olmadan yapılan kaynak artırımları çoğu zaman maliyeti yükseltir fakat asıl sorunu çözmez. Örneğin darboğaz veritabanındaysa worker sayısını artırmak sistemi daha da zorlayabilir.

En sık yapılan kapasite planlama hataları

En yaygın hata, her performans sorununu worker sayısını artırarak çözmeye çalışmaktır. Worker sayısı arttıkça PostgreSQL ve Redis üzerindeki yük de artar. Bağlantı limitleri, disk I/O kapasitesi ve network gecikmesi dikkate alınmadığında sistem daha fazla paralellik üretir ama daha kararsız çalışır.

Bir diğer kritik hata, test ortamındaki performansı üretim ortamına doğrudan uyarlamaktır. Gerçek webhook trafiği, üçüncü taraf API limitleri, dosya boyutları ve zamanlanmış görev çakışmaları üretimde farklı davranır. Bu nedenle büyüme öncesinde kontrollü yük testi yapılması, minimum ve maksimum eş zamanlı işlem değerlerinin belirlenmesi gerekir.

Pratik sunucu mimarisi önerisi

Kurumsal kullanımda güvenli başlangıç için n8n ana uygulamasını, worker node’larını, Redis’i ve PostgreSQL’i mantıksal olarak ayırmak iyi bir yaklaşımdır. İlk aşamada aynı fiziksel altyapı üzerinde ayrı container’lar kullanılabilir; trafik arttıkça worker node’ları ayrı sunuculara taşınabilir.

Büyüyen n8n worker yapısı için sunucu gereksinimleri belirlenirken esnek ölçeklenebilirlik ön planda tutulmalıdır. Worker node eklemek kolay, veritabanı taşımak ise daha risklidir. Bu nedenle PostgreSQL için hızlı SSD, düzenli yedekleme, bağlantı havuzu ve yeterli bellek planlaması erken aşamada düşünülmelidir.

Başlangıç için orta ölçekli bir kurulumda ayrı PostgreSQL sunucusu, ayrı Redis servisi ve en az iki worker node kullanmak hem bakım kolaylığı hem de kesinti riskini azaltır. Trafik arttığında yalnızca worker katmanını genişletmek, tüm sistemi yeniden kurmaktan daha kontrollü ve düşük riskli bir büyüme sağlar.