Basit Bir Canlı Sohbet Neredeyse Bu Sürümü Batırıyordu

Temel bir canlı sohbet sistemi son sürümümü neredeyse mahvediyordu.

Kulağa basit geliyor. Yakındaki kullanıcıları gösteriyorsunuz ve konuşmalarına izin veriyorsunuz. Ancak teknik gerçek çok daha zor. Canlı sohbeti coğrafi konum (geolocation) ve bir puanlama sistemiyle bağlamam gerekiyordu. Bu durum, arka planda devasa bir karmaşıklık yarattı.

Mimari:

• Frontend: React ve TypeScript. • Backend: Express ve WebSockets ile Node.js. • Veritabanı: Kullanıcılar ve puanlamalar için PostgreSQL. • Önbellek: Aktif oturumlar ve çevrimiçi durumu (presence) için Redis.

Coğrafi Konum Sorunu

Kullanıcıları konuma göre eşleştirmek kolay değil. Birçok uç durumu (edge case) yönetmem gerekiyordu:

  • Enlem ve boylamın saklanması.
  • Mesafeyi sorgulamak için Postgres eklentilerinin kullanılması.
  • Konum izinlerini reddeden kullanıcıların yönetilmesi.
  • Bir kullanıcı uygulamayı açmadan hareket ettiğinde güncelliğini yitirmiş verilerin yönetilmesi.

Bunu tekrar yapacak olsaydım, konum toplama işlemini eşleştirme işleminden ayırarak farklı servislere bölerdim.

Canlı Sohbet Gerçekliği

WebSockets gerçek zamanlı özellikler getirir ancak beraberinde kaos da getirir. Farklı sunucular arasında mesaj göndermek için Redis pub/sub kullandım.

En zor kısımlar şunlardı:

  • Kullanıcılar beklenmedik şekilde bağlantıyı kestiğinde bağlantıları temizlemek.
  • Mesajların, kullanıcının ayrıldığı odalara gönderilmesini engellemek.
  • Hayalet oturumlar (ghost sessions) oluşturmadan yeniden bağlanma süreçlerini yönetmek.

Basit bayraklar (flags) kullanmaktansa resmi bir durum makinesinin (state machine) daha iyi olduğunu öğrendim.

Puanlama Sistemi

Puanlama sistemini inşa edene kadar önemsiz görünür. Şunları sağlamam gerekiyordu:

  • Kullanıcıların aynı oturumu iki kez puanlayamaması.
  • Puanların profil görüntülemeleri için hızlıca birleştirilmesi (aggregate).
  • Verilerin uygulama genelinde tutarlı kalması.

Tekrarları önlemek için oturum kimlikleri (session IDs) üzerinde benzersiz kısıtlamalar (unique constraints) kullandım ve performansı korumak için ortalamaları önbelleğe aldım.

Öğrenilen Dersler

Eğer bunu bugün yeniden inşa etseydim, üç şeyi değiştirirdim:

  1. Eşleştirme ve sohbeti ayrı modüllere ayırmak.
  2. WebSocket bağlantı durumları için açık (explicit) modelleme kullanmak.
  3. İlk günden itibaren sohbet ve eşleştirme için daha iyi günlükler (logs) ve metrikler eklemek.

Yazılım geliştirmek bir dizi küçük karardan ibarettir. Bu kararlar, sisteminizin temiz mi yoksa kırılgan mı olacağını belirler.

Hiç canlı sohbet veya eşleştirme sistemi kurdunuz mu? Siz neyi farklı yapardınız?

Kaynak: https://dev.to/jaeger974/simple-live-chat-almost-sank-this-release-2pn7