Kullanıcı bildirimi anında ekranda görmek istiyor; canlı skor, sohbet, işlem durumu... Gerçek zamanlı veri akışının iki yaygın yolu var: çift yönlü WebSocket ve tek yönlü Server-Sent Events. Doğru soru "hangisi daha iyi?" değil, "hangi yönde hangisi?" sorusu. Yanlış seçim, gereksiz altyapı ya da eksik özellik olarak projenin faturasına yansır; ilk haftada doğru yönde karar vermek, sonradan yapılacak her düzeltmeden daha ucuzdur.

İki Yön mü, Tek Yön mü?

WebSocket, TCP üzerinden yükseltilen çift yönlü bir kanal açar; istemci de sunucu da dilediği an gönderir. Sohbet, oyun ve ortak düzenleme panoları gibi gerçek iki yönlü senaryoların doğal ev sahibidir. Server-Sent Events ise sıradan HTTP üzerinden sunucudan istemciye doğru akan metin akışıdır; tarayıcı tarafındaki tüm API'si birkaç satırdır:

const akis = new EventSource("/api/bildirimler");
akis.addEventListener("yeni", (olay) => {
  const veri = JSON.parse(olay.data);
  bildirimEkle(veri.baslik);
});
akis.onerror = () => konsolaYaz("baglanti koptu, tarayici yeniden deneyecek");

Sunucu tarafı da sıradan bir HTTP yanıtıdır; Content-Type: text/event-stream başlığı ve boş satırlarla ayrılmış data: satırları yeterlidir. Proxy ve CDN'lerin dilinden konuşan tam da budur; kurumsal güvenlik duvarlarının arkasında WebSocket yükseltmesinin takıldığı ortamlarda SSE çoğu zaman tek sorunsuz seçenek olur. Yenileme yerine akış, sayfa yenilenmeden güncel kalmak isteyen her panel için de düşük ortak payzadır: fiyat listeleri, sıralama tabloları, bildirim zilleri.

Yeniden Bağlanma ve Ölçek

SSE'nin en az konuşulan üstünlüğü otomatik yeniden bağlanmadır: bağlantı koptuğunda tarayıcı kendiliğinden tekrar dener, Last-Event-ID başlığıyla da kaldığı yerden devam edebilir. WebSocket'te bu mekaniği kendiniz yazarsınız; kalp atışı, üstel geri çekilme ve bağlantı kurtarma da size aittir. Yatay ölçeklemede ise her iki teknolojide de kalıcı bağlantı tutan sunucular arasında bir yayın katmanı kurmak gerekir; Redis pub/sub ya da ayrılmış bir mesaj kuyruğu bu katmanın standart yapı taşlarıdır. Ölçekleme hikâyesinin en pahalı bölümü budur: on binlerce bağlantının olduğu bir sistemde tek bir düğüme bağımlılık, tek bir yeniden başlatmanın binlerce istemciyi aynı anda koparması anlamına gelir; yeniden bağlanma fırtınasını önlemek için istemcileri aşamalı geri çekilmeyle (jitter dahil) geri çağırmak şarttır.

Karar Tablosu

Sadece sunucudan veri itiyorsanız SSE çoğu zaman yeterli, daha basit ve operasyonel maliyeti düşüktür. İstemcinin de anlık konuşması gerekiyorsa WebSocket kaçınılmazdır. İkisini birden taşıyan hibrit kurgular da mümkündür: bildirimler SSE, ortak düzenleme WebSocket. Böyle bir hibrit kurguda iki bağlantının durum yönetimini ayrı katmanlarda tutmak, hata ayıklamada işinizi epey kolaylaştırır. Karar tablonuzda üç sütun tutun: verinin yönü, kesintiye tolerans ve operasyon bütçesi. Önemli olan seçimi teknolojinin modasından değil, verinin yönüne göre yapmaktır; çünkü yeniden bağlanma stratejisi, gerçek zamanlılığın asıl sınavının yapıldığı yerdir. Bağlantı kurulduğunda ve koptuğunda kullanıcıya durumu gösteren bir göstergenin eklenmesi, bu sınavın en kolay kazanılan sorusudur. Kullanıcı, bağlantının kendisi yerine verinin güncelliğini sezdiğinde, gerçek zamanlılık özelliğiniz tamamlanmış olur.