Realtime backend maliyeti: WebSocket, polling ve fan-out

Kimler için?

Sohbet, canlı durum, takip ve ortak çalışma özellikleri tasarlayan mobil ekipler.

Başlamadan önce

Güncelleme sıklığı, kanal yapısı ve eşzamanlı oturum tahmini.

1. Gerçek zamanlılık hedefini netleştirin

“Anında” ifadesi tek başına ölçülebilir bir hedef değildir. Bir sipariş durumunun birkaç saniye gecikmesi kabul edilebilirken ortak editör daha kısa gecikme gerektirebilir. Sunucu olayının oluşması ile cihazın ekranında görünmesi arasındaki süreyi ölçün. Gecikme hedefiyle birlikte kaç cihazın aynı anda güncelleme beklediğini yazın. Offline cihaz için de daha sonra doğru durumu çekme yöntemi gerekir.

2. WebSocket ile polling’i koşullara göre seçin

WebSocket sürekli bağlantı sağlar; bağlantı yönetimi, heartbeat, yetki ve backpressure tasarımı ister. Polling daha basit olabilir ama çok sık yapıldığında gereksiz istek oluşturur. ETag ile değişmeyen cevabın gövdesini göndermemek faydalıdır; sunucudaki kontrolün tamamen ücretsiz olacağı varsayılmamalıdır.

3. Fan-out hesabı yapın

Bir mesajın 100 kişiye ulaşması tek bir teslim değildir. Varsayımsal olarak saniyede 10 olay, olay başına 100 alıcı ve 500 bayt gövde yaklaşık 500.000 bayt/s gövde aktarımı oluşturur. Protokol, TLS ve tekrar teslimler ayrıca yük ekler. Aynı odaya erişemeyen kullanıcıların kanala abone olmasını engelleyin; konu adı tahmin etmek yetki kazandırmamalıdır.

Yaklaşık gövde trafiği = olay/s × alıcı/olay × bayt/mesaj
10 × 100 × 500 = 500.000 bayt/s (protokol giderleri hariç)

4. Yeniden bağlanma ve eksik olayları çözün

Sunucu yeniden başladığında bütün cihazlar aynı anda bağlanırsa normal yükün üstünde kısa bir yoğunluk oluşur. Jitter içeren geri çekilme kullanın. Olaylara sıralı kimlik veya cursor verin; istemci son aldığı noktadan eksik değişiklikleri sorgulayabilsin. WebSocket’in açık olması her olayın kesin olarak işlendiğini göstermez. Önemli iş etkilerini ayrı kalıcı kayıtla doğrulayın.

5. Mobil yaşam döngüsünü hesaba katın

İşletim sistemi uygulamayı arka planda sınırlar; sürekli bağlantıya dayalı bir ekranı arka plan teslim garantisi olarak sunmayın. Kullanıcı uygulamaya dönünce güncel durumu API’den alın. Push, kullanıcıya uyarı taşıyabilir; uygulamadaki kaydın otoritesi backend verisidir. Mesaj içerikleri ve bağlantı loglarında hassas veri tutmaktan kaçının.

6. Testte sadece bağlantı saymayın

Açık bağlantı, mesaj teslim gecikmesi, kuyruk boyutu, düşürülen olay ve yeniden bağlanma oranını birlikte ölçün. Yavaş bir istemci tüm odayı etkilememeli; kuyruk sınırı ve koparma politikası olmalıdır. Planlanan kaynak paketlerinden eşzamanlı bağlantı garantisi çıkarmayın. Temsili bir sohbet veya durum akışıyla ölçmeden kapasite sonucu yayınlamayın.