"Chat Özelliği Ekleyelim" Dendiğinde...

Hiçbir yazılımcının kaçamayacağı o an: Müşteri toplantıda "Whatsapp gibi mesajlaşma istiyoruz" veya "Borsa verileri anlık aksın" der.

Bunu duyunca aklınıza hemen "WebSocket" geliyor, değil mi? Haklısınız ama eksik. WebSocket kurmak 10 dakikalık iş (Socket.io sağ olsun) ama onu 10.000 kullanıcıyla production'da stabil tutmak tamamen başka bir hikaye.

Üstelik çoğu zaman WebSocket fazla bile kaçabilir. Gelin şu 3 silahşörü masaya yatıralım: WebSocket, Server-Sent Events (SSE) ve Long Polling.

Bölüm 1: Hangi Silahı Seçmeli? (Karşılaştırma)

Bölüm 2: WebSocket - Ağır Siklet Şampiyonu

Gerçek zamanlı, çift yönlü etkileşim (chat, multiplayer oyun) için kraldır. TCP bağlantısını açık tutar ve veri "akışını" sağlar.

Derin Dalış:

Handshake: İletişim HTTP ile başlar, sonra Upgrade: websocket header'ı ile "protokol yükseltilir".
Connection Pooling Problemi: Tek bir sunucuda 100.000 bağlantı tutamazsınız. Node.js event loop tıkanır.
Çözüm: Yatay ölçekleme (Horizontal Scaling). Ancak bu sefer de "A kullanıcısı Server 1'de, B kullanıcısı Server 2'de, nasıl konuşacaklar?" sorunu çıkar.
Redis Pub/Sub: Kurtarıcı budur. Sunucular aralarında Redis üzerinden konuşur. Server 1 mesajı Redis'e atar, Server 2 oradan alıp kendi kullanıcısına iletir.

Bölüm 3: Server-Sent Events (SSE) - Sessiz Kahraman

Çoğu durumda (bildirim sistemi, borsa takibi, canlı maç skoru) istemciden sunucuya veri gitmesi gerekmez. Sadece sunucu konuşur, istemci dinler. İşte SSE bunun için yapılmıştır.

Neden Harika?

Standart HTTP kullanır. WebSocket gibi özel protokol dertleri, firewall engelleri yoktur.
Tarayıcı otomatik olarak reconnect olur. İnternet koptu geldi, SSE kaldığı yerden devam eder.
Basittir. Express ile 5 satırda yazarsınız.

Örnek (Express):

app.get('/stream', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
 
  setInterval(() => {
    res.write(`data: ${new Date().toLocaleTimeString()}\n\n`);
  }, 1000);
});

Bölüm 4: Long Polling - Eski Dost (Fallback)

Hiçbir şeyin çalışmadığı yerde Long Polling çalışır. Mantık basittir: İstemci "Yeni mesaj var mı?" diye sorar. Sunucu "Henüz yok, bekle" der ve cevabı bekletir (pending). Mesaj gelince cevabı döner. İstemci cevabı alır almaz tekrar sorar.

Günümüzde ana yöntem olarak kullanılmaz ama WebSocket bağlantısının kurulamadığı kurumsal ağlarda (proxy engelleri) "fallback" olarak hayat kurtarır.

Bölüm 5: Production Tuzakları (Gotchas)

Hangi yöntemi seçerseniz seçin, production'da şunlara dikkat edin:

Connection Limit: Tarayıcılar aynı domain'e (HTTP/1.1) en fazla 6 bağlantı açabilir. 7. sekmede uygulamanız çalışmaz. HTTP/2 bu sorunu çözer.
Memory Leak: Bağlantı koptuğunda (kullanıcı sekmeyi kapattığında) sunucu tarafında temizlik yapmazsanız (clearInterval, unsubscribe), sunucunuzun RAM'i şişer ve patlar.
Load Balancing: WebSocket kullanıyorsanız "Sticky Session" (aynı kullanıcı hep aynı sunucuya gitsin) ayarını Load Balancer'da (Nginx, AWS ALB) açmanız gerekir. Yoksa handshake kopar.

Sonuç: Karar Ağacı

Chat mi yapıyorsun? -> WebSocket (Socket.io)
Google Docs gibi ortak düzenleme mi? -> WebSocket + CRDT/OT
Sadece "Siparişiniz onaylandı" bildirimi mi? -> Server-Sent Events (SSE)
Admin panelde canlı log mu akacak? -> SSE
Mobil uygulama ve şarj önemli mi? -> Push Notification (FCM/APNS) kullan, socket'i açık tutma.

Teknoloji fetişizmine gerek yok. İhtiyacı en basit çözen araç, en doğru araçtır. Real-time mimarinizi kurgularken ölçekleme sorunlarından korkuyorsanız, teknik danışmanlık için kapım açık.

Real-Time İletişim Rehberi: WebSocket vs SSE vs Long Polling