Vercel'de WebSocket, Neon'da canlı sorgular: veriye ne zaman saniye, ne zaman dakika yeter

Ekim'de birkaç platform aynı anda gerçek zamanlı çalışma duyurdu. Vercel, fonksiyonlarındaki WebSocket desteğini betadan çıkardı, Neon canlı SQL sorguları yaptı, Stripe ödemeleri Supabase ve Neon'daki Postgres'e kendisi yazmaya başladı, Netflix de reklam olayları hattını canlı yayınlar için nasıl yeniden kurduğunu anlattı. İşletme sahibi için bunun arkasında tek bir soru var: şirketteki hangi veriler bir saniyede güncellenmeli, hangilerine bir dakika yeter, hangilerine de gece aktarımı. Sistemin maliyeti ve kaç noktada durabileceği bu cevaba bağlı.

Neler çıktı, kimde

Vercel 20 Ekim'de changelog'da Vercel Functions'ta WebSocket desteğinin genel kullanıma açıldığını yazdı. Haziran sonunda açık beta başladığından beri CDN'leri 300 milyon bağlantıya hizmet vermiş, şu an günde 15 milyon. Bağlantılar sıradan fonksiyon çağrıları gibi ücretlendiriliyor; Active CPU tarifesinde işlemci süresi yalnızca mesaj işlenirken sayılıyor.

Neon'un blogunda 15 Ekim'de Neon Realtime'ın açık betada olduğunu anlatan kısa bir not çıktı: herhangi bir SQL sorgusunu canlı hale getirip ona abone olabiliyorsunuz, sonuç da veri değiştikçe güncelleniyor. Tekrar tekrar sorgu atmaya gerek kalmıyor.

Supabase 15 Ekim'de Stripe Data Pipeline'ın Stripe verilerini Supabase'e nasıl senkronize ettiğini anlattı. Bağlantı Stripe panelinden kuruluyor. Stripe önce geçmişi yüklüyor, sonra veriyi güncel tutuyor: ödemeler, iadeler, itirazlar, müşteriler, abonelikler ve faturalar, stripe_sdp önekli ayrı bir şemaya tablolar halinde geliyor. Stripe yalnızca bu şemaya erişimi olan ayrı bir rolle ve kısa ömürlü token'larla bağlanıyor, veritabanı parolası kullanılmıyor. Neon 16 Ekim'de aynısını kendi Postgres'i için duyurdu: bağlantı Stripe panelinden, ödemelerle ilgili canlı veri de uygulama verisinin yanında.

Netflix 14 Ekim'de reklam olayları hattı hakkındaki yazısının ikinci bölümünü yayımladı. Eskiden reklam sunucusu her gösterimde meta verileri senkron olarak global bir kayıt defterine yazıyor ve onayı bekliyordu. Canlı yayınlar için bu uygun değildi: Jake Paul ile Mike Tyson maçını 100 milyondan fazla kişi izledi ve tek bir reklam arası, kritik yolda saniyede milyonlarca zorunlu veritabanı yazması demek olurdu. Netflix mühendisleri veritabanına yazmayı Apache Flink'te bir akış birleştirmesiyle değiştirdi: sunucu neyi gösterdiğini log'a yazıyor, cihazlardan gelen olaylarla eşleştirme sonra yapılıyor. Depolama arızası artık gösterimi durdurmuyor.

Örnek: üç veri hızı olan bir kiralama şirketi

Bir araç kiralama şirketini ele alalım. Teslim noktasındaki yönetici aracın boş olup olmadığına ve kontrol fotoğraflarına bakıyor. Ona şu anki durum lazım: aynı araca yapılan iki rezervasyon bir dakika bile çakışırsa müşteri tezgahta bekler. Muhasebeci dünkü ödemeleri kontrol ediyor, ona sabah aktarımı yeter. Ofisteki filo doluluk panosu bir dakika geride kalabilir, kimse fark etmez.

Bütün akışları WebSocket'ten geçirirseniz, dakikada bir sorgunun yeteceği bir pano için bağlantı parası ödersiniz. Her şeyi gece toplarsanız, teslim noktasındaki yönetici bir arkadaşını arayıp aracı biri almış mı diye sorar. Netflix'te aynı sorun başka bir ölçekte: müşteriye giden yoldaki her zorunlu senkron adımın bir gerekçesi olmalı.

Kanalı nasıl seçiyorum

2021'den beri çalıştığım ABD'deki PDR şirketinde 4 televizyondaki TV panoları gerçek zamanlı güncelleniyor: şirket sahibi, üretim, ön büro ve satışçılar iş yükünü ve siparişlerin hareketini görüyor. IVR'a gelen arama CRM'de hemen lead oluşturuyor, çünkü burada gecikmenin bedeli müşteri. Satışçılar için süper uygulama ise offline first kuruldu: sahada satışçı bağlantı olmadan fotoğraf çekiyor ve lead'i yürütüyor, uygulama da veriyi bağlantı gelince senkronize ediyor.

2023'te Londra'daki bir danışmanlık şirketi için Scraper Hub'ı yaptım, 120 kaynaktan haber toplayan bir servis. Toplamanın ilerleyişi arayüzde WebSockets üzerinden gösteriliyordu, çünkü kullanıcı toplamayı başlatıp sonucu bekliyordu. Bir üretim şirketi için yaptığım sipariş hesaplama programında da sunucu ile istemci WebSocket üzerinden bağlı: hesaplama ortalama 65 saniye sürüyor ve tasarım mühendisi ne olduğunu görüyor.

Şirket içi bir servis olan “Birlikte Kahve”de ise tedarikçinin kataloğu zamanlanmış olarak senkronize ediliyor, haftada en fazla üç çalıştırma. Sipariş tutarı, organizatör gerçek sepeti kontrol ettikten sonra çıkıyor. Burada kimsenin bir saniyeye ihtiyacı yok; tedarikçinin API'sine sürekli bağlantı ise bir şeyin bozulabileceği yerleri artırırdı. Vercel'deki WebSocket'i, Neon'un canlı sorgularını ve Stripe'ın hattını kendimde denemedim, açıklamalarına göre değerlendiriyorum.

Ben ne yapardım

Şirketteki veri akışlarını yazın ve her biri için bir dakikalık ve bir saatlik gecikmenin bedelini belirtin.

Saniyelik akışlar için WebSocket ya da canlı sorgu kullanın, ama yedekli: bağlantı koparsa istemci bütün durumu yeniden istesin.

Dakikalık akışlar için tekrar denemeleri ve çift işlemeye karşı koruması olan bir arka plan worker'ı kurun.

Dış servisleri kritik yoldan çıkarın. Ödeme sistemi ya da CRM çökerse araç teslimi devam eder, veri sonra ulaşır.

Maliyeti hesaplayın: platformda bağlantılar için fonksiyon çağrısı gibi ödersiniz, kendi sunucunuzda ise bellek harcarlar ve limitlerin takibini gerektirirler.

Arka plan görevlerini ve tekrar denemeleri worker'lar hakkındaki yazıda ve sonucu ikilemeyen tekrar işleme incelemesinde anlattım. Bu incelemedeki projeler: PDR şirketi, Scraper Hub ve üretim için sipariş hesaplama. Televizyonlar ve leaderboard için ekibe kötü kararlar öğreten metrikler incelemesi var, platformların maliyeti için Vercel, Fly ve Supabase'deki backend'ler incelemesi, tek sunucuda gözlemlenebilirlik için de bu inceleme. Hizmet alanları: iç sistemler ve API entegrasyonları. Şu ankinden daha hızlı güncellenmesi gereken verileriniz varsa hangileri olduğunu ve nedenini anlatın. Görevi konuşalım.