Node.js ve Express.js ile Ölçeklenebilir Backend Mimarisi

Ölçeklenebilir bir Node.js + Express.js backend; doğru LTS sürümü, katmanlı mimari, öngörülebilir middleware sırası, veritabanı/cache ayrımı ve yatay ölçeklemeye uygun süreç modeliyle kurulur. Asenkron olay döngüsü yüksek eşzamanlı I/O için uygundur; ancak CPU-yoğun iş, paylaşılan bellek varsayımı veya düzensiz hata yönetimi büyümeyi bozar. Bu yazıda üretimde işe yarayan mimari seçimleri, Express middleware disiplini ve Node sürüm stratejisini adım adım özetliyoruz.

Node.js neden backend için hâlâ güçlü bir seçenek?

Node.js, tek iş parçacıklı olay döngüsü ve non-blocking I/O modeli sayesinde API gateway, BFF (Backend for Frontend), gerçek zamanlı bildirim ve I/O-ağırlıklı mikroservislerde düşük gecikmeyle yüksek eşzamanlılık sunar. Aynı dilin (JavaScript/TypeScript) istemci ve sunucuda kullanılması ekip hızını artırır; npm ekosistemi kimlik doğrulama, kuyruk, gözlemlenebilirlik ve ORM tarafında olgun seçenekler sağlar.

Sınırlar da net olmalı: uzun süren CPU hesapları olay döngüsünü bloke eder. Bu işler worker thread, ayrı bir job worker veya özel bir servise taşınmalıdır. Ölçeklenebilirlik “daha fazla async/await” demek değildir; paylaşılmayan durum (stateless süreçler), dışarıda tutulan oturum/cache ve ölçülebilir limitler demektir.

Üretim için Node sürüm stratejisi (LTS)

Resmi Node.js sürüm sayfasına göre (2026 Eylül itibarıyla) üretim hatlarında Active LTS veya Maintenance LTS kullanılmalıdır. Odd numaralı Current hatları kısa ömürlüdür ve üretim için uygun değildir (Node 27 ile yıllık modele geçiş başlayana kadar bu kural geçerlidir).

• Node.js 24 (Krypton): Active LTS — yeni üretim sistemleri için birincil hedef; Active LTS başlangıcı 28 Ekim 2025, planlanan EOL 30 Nisan 2028.

• Node.js 22 (Jod): Maintenance LTS — hâlâ güvenlik yamaları alır; planlanan EOL 30 Nisan 2027. Stabil çalışan sistemlerde kontrollü yükseltme planı yeterlidir.

• Node.js 26: Current (Mayıs 2026’da çıktı) — kütüphane uyumluluğu için takip edilir; LTS’ye geçiş takvimi Ekim 2026 civarıdır. Kritik üretim trafiğini Current’a taşımak genelde erken bir risktir.

• Node.js 20 ve daha eski hatlar EOL’dir; güvenlik yaması almazlar, yükseltme planı zorunludur.

Pratik kural: CI’da LTS’yi sabitleyin (ör. 24.x), engines alanını package.json’da belirtin, staging’de bir minor/LTS adımı önce doğrulanmadan production’a geçmeyin. Container imajlarında node:24-bookworm-slim gibi sürüm-pin’li etiketler, “latest” etiketlerinden daha güvenlidir.

Mimari seçenekler: monolit, katmanlı servis, mikroservis

Express ile ölçeklenebilirlik çoğu zaman ilk günden mikroservis demek değildir. Aşağıdaki karşılaştırma, ekip boyutu ve operasyon olgunluğuna göre seçim yapmanıza yardımcı olur.

Monolit (tek deploy birimi)

• Ne zaman: MVP, küçük ekip, tek ürün alanı, henüz net bounded context yok.

• Güçlü yan: basit deploy, tek izleme yüzeyi, hızlı iterasyon.

• Zayıf yan: büyüdükçe deploy riski ve kod sahipliği bulanıklaşır.

• Ölçek: dikey + birden fazla monolit replikası (stateless) ile yatay.

Katmanlı / modüler monolit (önerilen varsayılan)

• Ne zaman: ürün netleşti, birden fazla domain var ama operasyon henüz onlarca servisi kaldırmıyor.

• Güçlü yan: routes → controllers/handlers → services → repositories ayrımı; test ve sahiplik kolaylaşır.

• Zayıf yan: disiplin bozulursa “klasörlü monolit”e geri döner.

• Ölçek: modül sınırları korunarak önce süreç/replika, sonra gerçekten gereken domain’i ayırma.

Mikroservisler

• Ne zaman: bağımsız ölçek/deploy ihtiyacı, ayrı ekipler, farklı SLO’lar.

• Güçlü yan: izolasyon, teknoloji çeşitliliği, hedefli ölçekleme.

• Zayıf yan: ağ gecikmesi, dağıtık işlem, gözlemlenebilirlik ve platform maliyeti yüksek.

• Ölçek: servis başına; Express çoğu zaman edge/BFF veya tek domain API’si olarak kalır.

Özet tablo (karar çerçevesi): küçük ekip + tek ürün → modüler monolit; domain ve ekip sınırları olgun + bağımsız deploy şart → seçici mikroservis. “Herkes mikroservis” varsayılanı nadiren doğru cevaptır.

Express.js ile sürdürülebilir API iskeleti

Express esnekliği hem avantaj hem risktir. Ölçeklenebilir bir API’de şu iskelet işe yarar:

1. Sürümlenmiş rotalar: /api/v1/... ile geriye dönük uyumluluk alanı bırakın.

2. İnce route katmanı: doğrulama ve HTTP eşlemesi; iş kuralları service katmanında.

3. Merkezi hata yönetimi: async hataları next(err) ile tek error middleware’e toplayın; stack’i loglayın, istemciye güvenli mesaj dönün.

4. Yapılandırma: secret’ları kodda tutmayın; ortam değişkeni + doğrulanmış config nesnesi kullanın.

5. TypeScript: DTO/şema (Zod/Yup) ile giriş doğrulama; tip güvenliği regresyon maliyetini düşürür.

Middleware sırası: güvenlik ve performansın sessiz omurgası

Express’te sıra önemlidir. Tipik ve güvenli bir sıra şöyle düşünülebilir:

1. İstek kimliği / correlation id (log birleştirme)

2. Helmet (HTTP güvenlik başlıkları)

3. Sıkıştırma (compression) — yanıt boyutuna göre; zaten sıkıştırılmış binary’lerde atlanır

4. JSON/body parser — boyut limiti ile (ör. 100kb–1mb; dosya yükleme ayrı multer/S3 akışı)

5. CORS — allowlist; production’da * kullanmayın

6. Rate limiting — IP + kullanıcı kimliği; auth öncesi brute-force, auth sonrası abuse koruması

7. Kimlik doğrulama (JWT/session) — korunacak rotalara uygulanır

8. Yetkilendirme (RBAC/scope)

9. İş handler’ları

10. 404 + merkezi error handler

JWT kullanıyorsanız access token’ı kısa ömürlü tutun, refresh token’ı httpOnly cookie veya güvenli saklama ile yönetin, alg: none ve zayıf secret tuzaklarına düşmeyin. Rate limit’i yalnızca global değil, login ve şifre sıfırlama uçlarında daha sıkı tanımlayın.

Veri katmanı: PostgreSQL, MongoDB ve Redis ne işe yarar?

İlişkisel bütünlük, raporlama ve karmaşık sorgular için PostgreSQL çoğu kurumsal üründe varsayılan doğru seçimdir. Esnek doküman modeli ve hızlı prototipleme gereken katalog/içerik benzeri alanlarda MongoDB yararlı olabilir. Redis ise birincil kaynak değil; cache, rate-limit sayaçları, kısa ömürlü session ve pub/sub için hız katmanıdır.

• Bağlantı havuzu: her Node süreci kendi pool’una sahiptir; replica sayısı × pool size veritabanı max connection’ı aşmamalıdır.

• N+1 sorguları: liste uçlarında join/dataloader veya tek sorguda toplama; ORM kullanıyorsanız sorgu log’unu staging’de açın.

• Cache: “cache-aside” ile başlayın; TTL ve invalidation’ı baştan tasarlayın. Cache’i doğruluk kaynağı sanmayın.

• Migrasyon: şema değişikliklerini geri alınabilir migrasyonlarla yönetin; production’da elle SQL kaçının.

Ölçekleme: cluster, process modeli ve kuyruklar

Tek süreçte Node bir CPU çekirdeğini iyi kullanır. Çok çekirdekli makinelerde PM2 cluster veya konteyner orkestrasyonunda birden fazla replica standart yoldur. Sticky session gerektiren durumlar (bellek içi session, bazı WebSocket kurulumları) yatay ölçeği zorlaştırır; session’ı Redis’e alın.

E-posta, PDF, görsel işleme, dış API senkronu gibi işleri istek döngüsünden çıkarıp kuyruğa (BullMQ/RabbitMQ/SQS) taşıyın. Böylece API p95 gecikmesi düşer, yeniden deneme ve backpressure yönetilebilir hale gelir. Sağlık kontrolü (/healthz) liveness ile readiness’i ayırın: süreç ayakta olsa bile veritabanı yoksa trafik almamalıdır.

Gözlemlenebilirlik olmadan ölçeklemek körlemedir

Ölçeklenebilir backend, metrik ve iz olmadan sadece “daha fazla sunucu” satın almaktır. Minimum set:

• Yapılandırılmış log (JSON): request id, user id (varsa), route, latency, status

• RED/USE metrikleri: istek oranı, hata oranı, süre; CPU/event loop lag; heap

• Dağıtık izleme (OpenTelemetry): dış HTTP ve DB span’leri

• Uyarilar: p95/p99 eşikleri, 5xx oranı, kuyruk derinliği, sertifika/TTL

Load test’i üretim kopyası benzeri ortamda, gerçekçi senaryolarla yapın. “Saniyede X istek” tek başına hedef değildir; hata oranı ve kuyruk birikimi ile birlikte okunmalıdır. Bu yazıda ajansa özel müşteri metrikleri uydurmuyoruz — kendi taban çizginizi ölçmeden kapasite planı yapmayın.

Headless CMS ve BFF: Payload örneği

İçerik ağırlıklı ürünlerde Express’i her şeyi yapan bir monolit yapmak yerine, Payload CMS gibi headless bir CMS içerik API’sini sunarken sizin BFF/API katmanınız kimlik, fiyatlandırma, sipariş veya mobil-özel toplama uçlarını yönetebilir. TypeScript ile paylaşılan tipler, sözleşme kırılmalarını erken yakalar. Önemli olan sınır: CMS içerik yaşam döngüsünden sorumlu olsun; iş kuralı ve yetkilendirme sizin servisinizde kalsın.

Kontrol listesi: canlıya almadan önce

• LTS Node + kilitli bağımlılıklar (package-lock/pnpm-lock)

• Helmet, CORS allowlist, body size limiti, rate limit

• Secret’lar ortamda; .env üretim imajına gömülü değil

• Stateless süreç + dışarıda session/cache

• Migrasyonlar, yedekleme ve geri alma planı

• Health/readiness, merkezi hata yönetimi, yapılandırılmış log

• Kuyruklanan arka plan işleri; istek içinde uzun CPU yok

• Staging’de yük ve güvenlik smoke testleri

Sonuç

Node.js ve Express.js ile ölçeklenebilir backend, doğru LTS, modüler sınırlar, disiplinli middleware, veri/cache ayrımı ve ölçüm ile gelir. Mikroservis bir ödül değil, maliyetli bir araçtır; çoğu ürün için iyi bir katmanlı monolit daha hızlı ve daha güvenlidir. Mimariyi büyüttükçe önce darboğazı ölçün, sonra parçalayın.

Ölçeklenebilir backend veya web yazılım projeniz için mimariyi birlikte netleştirmek isterseniz web yazılım projeleri hizmetlerimize göz atabilir veya doğrudan iletişime geçebilirsiniz.