PostgreSQL LISTEN/NOTIFY: Canlı Güncellemeler İçin Ne Zaman Yeterli?

LISTEN/NOTIFY'nin çözmeye çalıştığı problem nedir

Bir ürünün arayüzündeki “canlı güncellemeler” genellikle kullanıcı yenilemeye gerek kalmadan ekranda bir değişiklik olmasını sağlar. Bir gösterge panelindeki sayı artar, gelen kutusunda kırmızı bir rozet belirir, bir yönetici yeni bir siparişi görür ya da “Derleme tamamlandı” veya “Ödeme başarısız” diyen bir toast görünür. Önemli olan zamanlama: anlık gibi hissedilir, gerçekte bir veya iki saniye olsa bile.

Birçok ekip polling ile başlar: tarayıcı sunucuya her birkaç saniyede bir “yeni bir şey var mı?” diye sorar. Polling işe yarar, ama iki yaygın dezavantajı vardır.

İlk olarak, gecikmeli hissedilir çünkü kullanıcılar değişiklikleri yalnızca bir sonraki poll'da görür.

İkincisi, maliyetli olabilir çünkü hiçbir şey değişmediğinde bile sürekli kontroller yaparsınız. Bunu binlerce kullanıcı ile çarparsanız gürültüye dönüşür.

PostgreSQL LISTEN/NOTIFY daha basit bir vaka için vardır: “bir şey değiştiğinde haber ver.” Sürekli sormak yerine uygulamanız bekleyebilir ve veritabanı küçük bir sinyal gönderdiğinde tepki verebilir.

Bu, bir dürtü yeterli olan UI'lar için iyi bir eşleşmedir. Örneğin:

• Toplamlar değiştiği için bir pano kartının yenilenmesi gerekiyor
• Yeni bir öğe geldiği için rozet sayısı güncellenmeli
• Bir iş durumu değiştiği için dahili bir uyarı görünmeli

Takas basitlik ve garantiler arasındadır. LISTEN/NOTIFY Postgres içinde olduğu için eklemesi kolaydır, ama tam bir mesajlaşma sistemi değildir. Bildirim bir ipucudur, kalıcı bir kayıt değildir. Bir dinleyici bağlantısı kesilmişse sinyali kaçırabilir.

Pratik bir kullanım: NOTIFY uygulamanızı uyandırsın, sonra uygulamanız tabloları okuyup doğruyu alsın.

PostgreSQL LISTEN/NOTIFY nasıl çalışır (basitçe)

PostgreSQL LISTEN/NOTIFY'yi veritabanınıza yerleştirilmiş basit bir zil gibi düşünün. Uygulamanız zilin çalmasını bekleyebilir, sistemin başka bir parçası bir şey değiştiğinde çalabilir.

Bir bildirim iki parçadan oluşur: bir kanal adı ve isteğe bağlı bir yük. Kanal, bir başlık etiketi gibidir (örneğin orders_changed). Yük, eklediğiniz kısa bir metin mesajıdır (örneğin bir sipariş id'si). PostgreSQL hiç bir yapı zorunlu kılmaz, bu yüzden ekipler genellikle küçük JSON dizeleri gönderir.

Zili kim çalar?

Bildirim uygulama kodundan tetiklenebilir (API sunucunuz NOTIFY çalıştırır) veya veritabanının kendisinden bir tetikleyici ile (insert/update/delete sonrası NOTIFY çalıştıran bir trigger).

• Uygulama kodu takip edilmesi ve test edilmesi daha kolaydır.
• Tetikleyiciler, aynı tabloları birden çok yazarın değiştirdiği ve tutarlı davranış istediğiniz durumlarda yardımcı olur.

Alıcı tarafta, uygulama sunucunuz bir veritabanı bağlantısı açar ve LISTEN channel_name çalıştırır. Bu bağlantı açık kalır. Bir NOTIFY channel_name, 'payload' olduğunda, PostgreSQL o kanalı dinleyen tüm bağlantılara bir mesaj iletir. Uygulamanız sonra tepki verir (cache'i yenileme, değişen satırı alma, tarayıcıya WebSocket olayı itme vb.).

NOTIFY ne yapar (ve yapmaz)

NOTIFY bir sinyal olarak anlaşılmalı, teslimat servisi olarak değil:

• Dinleyicilere “şimdi bir şey oldu” der.
• Her mesajın alındığını garanti etmez (bağlantısı kesilen dinleyici kaçırır).
• Bir kuyruk değildir (mesajlar sonra için saklanmaz).
• Yük boyutu sınırlıdır ve küçük tutulmalıdır.
• Veriye işaret etmeli, yerine geçmemeli (id gönderin, sonra detayları sorgulayın).

Bu şekilde kullanıldığında PostgreSQL LISTEN/NOTIFY ekstra altyapı eklemeden canlı UI güncellemelerini sağlayabilir.

LISTEN/NOTIFY canlı UI güncellemeleri için ne zaman yeterlidir

LISTEN/NOTIFY, UI'nızın yalnızca bir şeyin değiştiğine dair bir dürtüye ihtiyaç duyduğu durumlarda parıldar, tam bir olay akışı yerine. "Bu widget'ı yenile" veya "yeni bir öğe var" gibi düşünün, "her tıklamayı sıralı olarak işle" değil.

Veritabanı zaten gerçeğin kaynağıysa ve UI'nın onunla senkron kalmasını istiyorsanız en iyi çalıştığı yer burasıdır. Yaygın bir desen: satırı yaz, küçük bir bildirim gönder (ID dahil), UI (veya bir API) en son durumu tekrar getsin.

LISTEN/NOTIFY genellikle şu durumlarda yeterlidir:

• Mesaj küçük bir “bir şey değişti” işaretiyse, tam yük değilse.
• Olay hacmi düşük ila orta seviyedeyse (patlamalı kısa süreli artışlar sorun değil, sürdürülebilir yüksek trafik sorun olur).
• Bir kullanıcı bir bildirimi kaçırırsa UI yeniden yükleme veya kısa süreli poll ile toparlanabiliyorsa.
• Mükemmel teslimat garantilerinden çok basitliği önemsiyorsanız (erken ürünler veya dahili araçlar için yaygın).
• Tek bir birincil veritabanınız varsa ve daha az hareketli parça istiyorsanız.

Somut bir örnek: dahili bir destek panosunda “açık talepler” ve “yeni notlar” rozeti gösterilir. Bir ajan not eklediğinde backend Postgres'e yazıp ticket_changed ile ticket ID'sini NOTIFY eder. Tarayıcı bunu WebSocket üzerinden alır ve yalnızca o bilet kartını yeniden getirir. Ekstra altyapı yok, UI yine canlı hisseder.

LISTEN/NOTIFY nerede kırılmaya başlar

LISTEN/NOTIFY başta harika hissedebilir, ama sert sınırları vardır. Bu sınırlar, bildirimleri bir mesaj sistemi gibi ele aldığınızda ortaya çıkar.

En büyük boşluk dayanıklılıktır. NOTIFY bir kuyruk işi değildir. Kimse dinlemiyorsa mesaj kaybolur. Bir dinleyici bağlıyken bile çökme, deploy, ağ sorunu veya veritabanı yeniden başlatma bağlantıyı koparabilir. Kaçırılan bildirimleri otomatik olarak geri almazsınız.

Bağlantı kopmaları kullanıcıya yönelik özellikler için özellikle can sıkıcıdır. Bir gösterge panelini düşünün: tarayıcı sekmesi uykuya girer, WebSocket yeniden bağlanır ve UI “takılı” görünür çünkü birkaç olayı kaçırmıştır. Bunun etrafında çözümler geliştirebilirsiniz, ama çözüm artık sadece "LISTEN/NOTIFY" olmaz: durumu tekrar sorgulayarak yeniden inşa edersiniz ve NOTIFY sadece yenileme için bir ipucu olur.

Fan-out başka yaygın bir sorundur. Bir olay yüzlerce veya binlerce dinleyiciyi uyandırabilir (birçok app server, birçok kullanıcı). orders gibi tek bir gürültülü kanal kullanırsanız, her dinleyici uyanır hatta çoğu sadece görmezden gelir. Bu, CPU patlamalarına ve bağlantı baskısına neden olabilir.

Yük boyutu ve sıklık son tuzaklardır. NOTIFY yükleri küçüktür ve yüksek frekanslı olaylar istemcilerin işleyebileceğinden daha hızlı birikebilir.

Şunlara dikkat edin:

• Garantili teslimat, yeniden denemeler veya sıralama garantilerine ihtiyaç duyuyorsanız.
• İstemciler sık yeniden bağlanıyor ve güncellemeleri kaçırmamaları gerekiyorsa.
• Bir kanal birçok dinleyiciyi uyandırıyor ve çoğu olayı görmezden geliyor.
• Büyük yükler gönderiyor veya saniyede çok sayıda olay tetikliyorsanız.

Bu noktada NOTIFY'ı bir "dürtü" olarak tutun ve güvenilirliği bir tabloya veya uygun bir mesaj aracısına taşıyın.

Adım adım: işe yarayan basit bir desen

LISTEN/NOTIFY ile güvenilir bir desen, NOTIFY'ı dürtü, veri kaynağını tablo olarak ele almaktır. Veritabanı satırı gerçektir; bildirim uygulamanıza ne zaman bakacağını söyler.

1) Yazın, commit edin, sonra notify yapın

Yazmayı bir işlem içinde yapın ve yalnızca veri değişikliği commit edildikten sonra bildirimi gönderin. Çok erken notify yaparsanız istemciler uyanır ve veriyi bulamayabilir.

Yaygın bir kurulum, INSERT/UPDATE tetikleyip küçük bir mesaj gönderen bir trigger'dır.

NOTIFY dashboard_updates, '{"type":"order_changed","order_id":123}'::text;

2) Basit kanal adları ve küçük yükler seçin

Kanal adlandırma, insanların sisteme nasıl düşündüğüne uyduğunda en iyi çalışır. Örnekler: dashboard_updates, user_notifications veya kiracı bazlı tenant_42_updates.

Yükü küçük tutun. Kimlikleri ve bir tür koyun, tam kayıtları değil. Faydalı bir varsayılan biçim:

• type (ne oldu)
• id (ne değişti)
• isteğe bağlı tenant_id veya user_id

Bu, bant genişliğini düşük tutar ve hassas verilerin bildirim günlüklerine sızmasını önler.

3) Yeniden bağlanmaları ve her bağlantıda yeniden abone olmayı yönetin

Bağlantılar kopar. Buna hazırlıklı olun.

Bağlandığınızda gereken tüm kanallar için LISTEN çalıştırın. Bağlantı koptuğunda kısa bir backoff ile yeniden bağlanın. Yeniden bağlandıktan sonra (abonelikler taşınmaz) tekrar LISTEN yapın. Yeniden bağlandıktan sonra kaçırılmış olayları kapatmak için “son değişiklikleri” kısaca yeniden getirin.

4) UI'yi güncelleme: önce tekrar getirin, sonra yamalayın

Çoğu canlı UI güncellemesi için yeniden getirme en güvenli hamledir: istemci {type, id} alır, sonra en güncel durum için sunucuya sorar.

İncremental patchleme daha hızlı olabilir fakat yanlış olması daha kolaydır (sırasız olaylar, kısmi hatalar). Orta yol olarak: küçük dilimleri yeniden getirin (bir sipariş satırı, bir bilet kartı, bir rozet sayısı) ve ağır toplu sorguları kısa bir zamanlayıcı ile tutun.

Panolar ve bildirimler için ölçekleme desenleri

Bir yönetici panosundan aynı sayıları izleyen pek çok kullanıcıya geçtiğinizde, iyi alışkanlıklar zekice SQL'den daha önemlidir. LISTEN/NOTIFY hâlâ iyi çalışabilir, ama olayların veritabanından tarayıcılara nasıl aktığını şekillendirmeniz gerekir.

Yaygın bir temel: her uygulama örneği bir uzun ömürlü bağlantı açar ve LISTEN yapar, sonra bağlı istemcilere güncellemeleri iter. "Her örnek için bir dinleyici" kurulumunun küçük sayıda sunucunuz varsa ve ara sıra yeniden bağlanmaları tolere edebiliyorsanız basit ve sıklıkla yeterlidir.

Eğer çok sayıda uygulama örneğiniz (veya serverless worker'ınız) varsa, paylaşılan bir dinleyici servisi daha kolay olabilir. Bir küçük süreç bir kez dinler, sonra güncellemeleri yığına fırlatır. Ayrıca toplama, metrik ve backpressure eklemek için tek bir nokta sağlar.

Tarayıcılar için genellikle WebSocket (çift yönlü, etkileşimli UI'lar için harika) veya Server-Sent Events (tek yönlü, panolar için daha basit) ile itersiniz. Her iki durumda da “her şeyi yenile” göndermekten kaçının. "Sipariş 123 değişti" gibi kompakt sinyaller gönderin ki UI yalnızca ihtiyacı olanı tekrar getirsin.

UI'nin çalkalanmasını önlemek için birkaç koruma ekleyin:

• Patlamaları debounce edin (örneğin 100–500 ms arası) before istemcilere göndermeden önce
• Kopyaları birleştirin (aynı kayıt 10 kez değiştiyse 1 güncelleme gönderin)
• Tam sayfa yenileme yerine widget başına “kirli bayraklar” kullanın

Kanal tasarımı da önemlidir. Tek bir küresel kanal yerine tenant, ekip veya özelliğe göre bölümlendirin ki istemciler sadece ilgili olayları alsın. Örnek: notify:tenant_42:billing ve notify:tenant_42:ops.

Yaygın hatalar ve nasıl önlenir

LISTEN/NOTIFY basit hissediyor; bu yüzden ekipler hızlıca yayınlar ve sonra üretimde şaşırır. Çoğu problem, onu garanti veren bir mesaj kuyruğu gibi kullanmaktan gelir.

1) Bildirimleri kalıcı mesajlar gibi görmek

Uygulamanız yeniden bağlanırsa (deploy, ağ arızası, DB failover), bağlı olmadığınız sırada gönderilen herhangi bir NOTIFY kaybolur. Çözüm: bildirimi bir sinyal olarak kullanın, sonra veritabanını tekrar kontrol edin.

Pratik desen: gerçek olayı bir tabloda saklayın (id ve created_at ile), sonra yeniden bağlandığınızda son gördüğünüz id'den daha yenileri için sorgulayın.

2) Yükü aşırı doldurmak

LISTEN/NOTIFY yükleri büyük JSON blob'lar için uygun değildir. Büyük yükler ekstra işlem, daha fazla ayrıştırma ve limitlere takılma riskini artırır.

Yükleri "order:123" gibi küçük ipuçları için kullanın. Uygulama sonra en güncel durumu veritabanından okur.

3) “Sinyal” ve “veri getirme”yı karıştırmak

Yaygın bir hata, UI'yı bildirim yüküne dayanarak tasarlamaktır, sanki o gerçek kaynakmış gibi. Bu, şema değişikliklerini ve istemci sürümlerini zorlaştırır.

Temiz bir ayrım tutun: bir şey değiştiğini bildir, sonra normal bir sorgu ile güncel veriyi al.

4) Çok sık tetiklenen tetikleyiciler

Her satır değişiminde NOTIFY yapan tetikleyiciler sisteminizi boğabilir, özellikle yoğun tablolar için.

Sadece anlamlı geçişlerde notify yapın (örneğin durum değişimleri). Gürültülü güncellemeler varsa, değişiklikleri batch'leyin (örneğin bir işlem veya zaman penceresinde tek notify) veya bu güncellemeleri notify yolundan çıkarın.

5) UI'de backpressure'ı görmezden gelmek

Veritabanı bildirim gönderebilse bile UI hâlâ boğulabilir. Her olayda yeniden render eden bir pano donabilir.

İstemci tarafında güncellemeleri debounce edin, patlamaları tek bir yenilemeye sıkıştırın ve “her delta'yı uygula” yerine “geçersiz kıl ve yeniden getir” yaklaşımını tercih edin. Örneğin: bir bildirim zili anında güncellenebilir, ama açılır liste her birkaç saniyede en fazla bir kez yenilensin.

Hızlı kontrol listesi: LISTEN/NOTIFY'in uygun olup olmadığına karar verin

LISTEN/NOTIFY, uygulamanın taze veriyi getirmesi için küçük bir “bir şey değişti” sinyali istediğinizde harikadır. Tam bir mesajlaşma sistemi değildir.

Önce bu soruları yanıtlayın:

• Bir dinleyici bir dakika çevrimdışı olursa olayları kaçırması kabul edilebilir mi? Kaçırmak kabul edilemezse dayanıklı teslimat ve yeniden oynatma gerekir.
• "Yakın gerçek zaman" yeterli mi? Kullanıcılar deploy veya ağ sorunları sırasında kısa bir gecikmeyi (veya manuel yenilemeyi) tolere edebiliyorsa LISTEN/NOTIFY genelde uygundur.
• Zirve patlama hızınız nedir? Saniyede birkaç olay veya ara sıra spike'lar uygundur. Sürekli yüksek hacim kanalları gürültülü ve yönetilmesi zor yapar.
• Aynı anda kaç tüketici dinleyecek? Bir veya birkaç backend işçi kolaydır. Yüzlerce veya binlerce bağlı istemci genelde fan-out katmanı (sunucunuz) istemeniz anlamına gelir.
• Birden çok olay türü arasında katı sıralama gerekiyor mu? Dashboard'unuz "A, B'den önce işlenmeli" gibi bağımlılıklara dayalıysa işler hızla karmaşıklaşır.

Pratik bir kural: NOTIFY'ı bir dürtü (go re-read the row) olarak kullanabiliyorsanız güvenli bölgedesiniz.

Örnek: bir yönetici panosu yeni siparişleri gösterir. Bir bildirim kaçırılırsa bir sonraki poll veya sayfa yenileme doğru sayıyı gösterir. Bu iyi bir uyumdur. Ancak "bu kartı tahsil et" veya "paketi gönder" gibi kritik ve geri alınamaz işler gönderiyorsanız, birini kaçırmak gerçek bir olaya yol açar.

Örnek: canlı pano ve kullanıcı bildirimleri

Küçük bir satış uygulaması hayal edin: bir pano bugünün gelirini, toplam siparişleri ve "son siparişler" listesini gösterir. Aynı zamanda, her satış elemanı kendi siparişleri ödendiğinde veya gönderildiğinde hızlı bir bildirim almalıdır.

Basit yaklaşım Postgres'i gerçeğin kaynağı olarak kullanmak ve LISTEN/NOTIFY'ı sadece bir dürtü olarak kullanmaktır.

Bir sipariş oluşturulduğunda veya durumu değiştiğinde backend aynı istekte iki şey yapar: satırı yazar (veya günceller) ve sonra küçük bir NOTIFY gönderir (genellikle sadece sipariş ID'si ve olay türü). UI NOTIFY yüküne tam veri için güvenmez.

Pratik akış şöyle görünür:

• Sipariş değişikliğini bir işlem içinde yazın.
• Commit'ten sonra orders_events kanalına {\"type\":\"status_changed\",\"order_id\":123} ile NOTIFY gönderin.
• Bir backend dinleyicisi olayları alır ve bağlı tarayıcılara (WebSocket veya SSE) iletir.
• Pano ihtiyacı olanı tekrar getirir: ID ile tek satır ve toplamlar için kısa bir zamanlayıcı (örneğin her 2–5 saniye) ile ağır hesaplamaları azaltır.
• Kullanıcı bildirimleri hedeflenir: sadece o siparişte abone olan satış elemanı "ödendi" veya "gönderildi" toast'ını alır.

Bu, NOTIFY'ı hafif tutar ve pahalı sorguları sınırlar.

Trafik arttığında çatlaklar görünür: olay patlamaları tek bir dinleyiciyi bunaltabilir, yeniden bağlanmada bildirimler kaçabilir ve garantili teslimat ile yeniden oynatma ihtiyacı doğar. Bu genelde daha güvenilir bir katman (outbox tablosu + işçi, sonra gerekirse broker) ekleme zamanıdır; Postgres yine gerçeğin kaynağı olmaya devam eder.

Ne zaman özel bir broker'a geçmeli

LISTEN/NOTIFY hızlı bir "bir şey değişti" sinyali için iyidir. Tam bir mesajlaşma sistemi olmak için tasarlanmamıştır. Olaylara güvenir hale geldiğinizde broker ekleme zamanı gelmiştir.

LISTEN/NOTIFY'i aştığınızı gösteren işaretler

Aşağıdakilerden herhangi biri ortaya çıkarsa bir broker size sorunları çözer:

• Dayanıklılığa ihtiyacınız var: uygulama yeniden başlasa veya DB failover olsa bile olaylar kaybolmamalı.
• Yeniden denemeler ve dead-letter yönetimi gerekir: bir tüketici başarısız olursa mesaj tekrar denenmeli ve izlenmelidir.
• Tüketici gruplarına ihtiyacınız var: birden çok işçi yükü paylaşsın, çift işlem olmasın.
• Denetim ve yeniden oynatma gerekiyor: "son bir saatte ne oldu" veya "bu görünümü olaylardan yeniden oluştur" gibi.
• Kontrollü backpressure lazım: üreticiler yavaş tüketicileri bunaltmamalı.

LISTEN/NOTIFY mesajları sonra için saklamaz. It bir itme sinyalidir, kalıcı bir log değil. Bu, pano widget'ını yenilemek için mükemmel ama "faturalandırmayı tetikle" veya "paketi gönder" gibi kritik iş akışları için risklidir.

Bir broker ne ekler (basitçe)

Bir broker size gerçek bir mesaj akışı modeli sağlar: kuyruklar (yapılacak işler), topic'ler (birçok alıcıya yayın), retention (mesajları dakikalar ya da günler boyunca tutma) ve acknowledgments (tüketici işlediğini onaylar). Bu, "veritabanı değişti"yi "bu yüzden olması gereken her şey"den ayırmanıza izin verir.

En karmaşık aracı seçmek zorunda değilsiniz. İnsanların değerlendirdiği yaygın seçenekler Redis (pub/sub veya streams), NATS, RabbitMQ ve Kafka'dır. Doğru seçim, basit iş kuyruklarına mı, birçok servise fan-out'a mı yoksa geçmişin yeniden oynatılabilmesine mi ihtiyacınız olduğuna bağlıdır.

Kademeli geçiş planı

Büyük bir yeniden yazmaya gerek kalmadan geçiş yapabilirsiniz. Pratik desen: NOTIFY'ı uyanma sinyali olarak tutarken broker'ı teslim kaynağı yapın.

İlk olarak olay satırını aynı işlem içinde bir tabloya yazın, sonra bir işçi bu olayı broker'a yayınlasın. Geçiş sırasında NOTIFY UI katmanına "yeni olayları kontrol et" demeye devam edebilir, arka plan işçileri ise broker'dan retry ve audit ile tüketir.

Böylece panolar hızlı kalır ve kritik iş akışları en iyi çaba bildirimlerine bağlı kalmaz.

Sonraki adımlar: küçük bir sürüm yayınlayın ve güvenle yineleyin

Bir ekran seçin (bir pano kartı, bir rozet sayısı, bir “yeni bildirim” toast'ı) ve uçtan uca bağlayın. LISTEN/NOTIFY ile dar kapsamlı tutulduğunda ve gerçek trafikte ölçtüğünüzde faydalı bir sonuç hızlıca alabilirsiniz.

En basit güvenli desenle başlayın: satırı yazın, commit edin, sonra küçük bir sinyal yayınlayın. UI sinyale tepki verip en güncel durumu (veya ihtiyacı olan dilimi) tekrar getirsin. Bu, yükleri küçük tutar ve mesajlar sırayla gelmediğinde ortaya çıkan ince hatalardan kaçınır.

Erken gözlemlenebilirlik ekleyin. Şık araçlara gerek yok ama sistem gürültülü hale geldiğinde cevap almanız şarttır:

• Yeniden bağlanmaları ve abonelik başlangıçlarını (sebep ile) loglayın
• NOTIFY oranını ve pik patlamalarını takip edin
• Bildirimlerin tetiklediği getirme oranını izleyin
• "Kaçırılmış güncelleme" belirtileri için izleme (kullanıcıların yenileme yapması) ekleyin

Anlaşmaları sıkıcı ve yazılı tutun. Kanal adları, olay adları ve yük şekli (sadece bir ID olsa bile) konusunda karar verin. Repoda kısa bir "olay kataloğu" sürüm sürüm sürüntüyü engeller.

Hızlı inşa etmek istiyorsanız ve yığını basit tutmak istiyorsanız, Koder.ai (koder.ai) gibi bir platform ilk sürümü React UI, Go backend ve PostgreSQL ile çıkarmanıza yardımcı olabilir; gereksinimler netleştikçe yineleyebilirsiniz.