Veri Tabanı Mühendisliğinde Devrim: PostgreSQL "LISTEN/NOTIFY" Sistemi Saniyede 60.000 İşleme Nasıl Ölçeklendi?

Yazılım dünyasında, PostgreSQL'in gerçek zamanlı pub/sub (yayınla/abone ol) mekanizması olan **LISTEN/NOTIFY** özelliğinin yüksek yük altında ölçeklenemediği yönünde yaygın bir inanış vardır. Ancak DBOS mühendisleri yayınladıkları teknik makalede bu miti çürüttü. Doğru optimizasyon adımlarıyla, tek bir Postgres sunucusunda milisaniye seviyesinde gecikmeyle saniyede **60.000 yazma (write) işlemine** ulaşılabileceği kanıtlandı.

Bu başarı, yapay zeka sohbet robotlarının (LLM token akışı) ve düşük gecikmeli veri akışlarının (real-time streaming) veritabanı maliyetini radikal biçimde düşürüyor.

Küresel Kilit (Global Lock) Sorunu ve Tıkanmanın Nedeni

PostgreSQL'in LISTEN/NOTIFY sisteminin varsayılan ayarlarda neden tıkandığı ve mühendislerin bunu nasıl çözdüğü şu şekilde açıklanıyor:

2.900 Sınırı ve Küresel Kilit: Standart bir tetikleyici (trigger) ile her yeni veri eklendiğinde NOTIFY çağrıldığında, sistem saniyede en fazla 2.900 işlem yapabiliyor. Bunun sebebi, Postgres’in bildirim sırasının işlem onay sırasıyla (commit order) birebir eşleşmesini garanti etmek için her commit sırasında **küresel bir özel kilit (global exclusive lock)** almasıdır. Bu kilit, işlemlerin paralel olarak değil, sırayla (ardışık) yazılmasına neden olarak sistemi kilitler.
Bellekte Arabelleğe Alma (Buffering & Batching): DBOS mühendisleri, her satır yazıldığında anında bildirim göndermek yerine, bildirimleri bellekte (in-memory) biriktirip belirli aralıklarla tek bir toplu işlem (batch transaction) olarak sunucuya gönderme yöntemini uyguladı. Bu sayede küresel kilidin alınma sıklığı düşürüldü ve yazma hızı 20 kat arttı.
Hata Toleransı ve Yedek Polling (Fallback): Arabelleğe alma yöntemi kullanıldığında, sunucu çökerse kuyruktaki bildirimler kaybolabilir. Bunu önlemek için okuyucu istemcilere düşük frekanslı (örneğin saniyede bir) yedek bir sorgulama (polling) döngüsü eklendi. Böylece bildirim kaybolsa bile veri akışı kesintiye uğramıyor.

Uygulama Modeli	Saniyede Yazma Kapasitesi (Throughput)	CPU / Kaynak Tüketimi	Gecikme Süresi (Latency)
Klasik NOTIFY (Tetikleyici ile)	~2.900 işlem/sn	Çok düşük (CPU boşta bekliyor, global kilit tıkanıklığı)	Milisaniye seviyesinde
Optimize Edilmiş Batch NOTIFY	~60.000 işlem/sn (20x Artış)	Tam kapasite (%100 CPU doygunluğu)	15 - 100 milisaniye

Database Sunucu Kablo Veritabani PostgreSQL — **Görsel:** PostgreSQL, Redis veya Kafka gibi harici bir mesaj kuyruğu (message broker) teknolojisine ihtiyaç duymadan, optimize edilmiş pub/sub mimarisiyle saniyede on binlerce gerçek zamanlı mesajı yönetebilir / **Görsel Kaynağı:** Unsplash

Redis ve Kafka İhtiyacını Azaltabilir

Gerçek zamanlı sohbet uygulamaları veya finansal işlemler geliştiren yazılımcılar, veri tabanının yanına genellikle Redis veya Apache Kafka gibi ek bir mesaj dağıtım katmanı kurmak zorunda kalıyordu. Bu durum hem sunucu maliyetlerini hem de sistem karmaşıklığını artırıyordu. DBOS ekibinin açık kaynaklı olarak yayınladığı benchmark kodları, PostgreSQL'in tek başına devasa bir mesaj kuyruğu gibi çalışabileceğini göstererek, yazılım mimarlarının veritabanı tasarımlarını basitleştirmelerine olanak tanıyor.

Kaynak: Hacker News (Öne Çıkanlar)

Veri Tabanı Mühendisliğinde Devrim: PostgreSQL "LISTEN/NOTIFY" Sistemi Saniyede 60.000 İşleme Nasıl Ölçeklendi?