Postgres'i message queue olarak kullanmak, duran worker'ları veritabanı kesintilerine dönüştürüyor

Bir dev.to yazısı, bir uygulamanın job queue'sunu doğrudan Postgres içinde çalıştırma alışkanlığının giderek yaygınlaştığını ve bunun iki sistemi sessizce tek bir hata alanında birleştirdiğini, bu birleşimin bedelinin ise ancak bir kesinti sırasında görünür hale geldiğini savunuyor. Yazı, bu desenin neden cazip olduğundan, altındaki veritabanına ne yaptığından ve sınırlarının nerede olduğundan bahsediyor.

Cazibesi ve gizli maliyeti

Makale, Postgres'in mesajlaşmayı diğer görevlerinin yanında halledebileceği yönündeki tavsiyeye karşı çıkıyor. Yaygın uygulama SELECT ... FOR UPDATE SKIP LOCKED üzerine kurulu; bu, worker'ların tek bir sorgu ve sıfır yeni altyapıyla bir tablodan job'ları rezerve etmesini sağlıyor: broker yok, ayrı bir operasyon yükü yok. Yazara göre tam da bu kullanışlılık sorunların kaynağı, çünkü queue, müşterilerinizin en çok bağımlı olduğu ve değiştirmesi en zor olan bileşenin içine gömülüyor.

MVCC, queue'ları pahalı hale getiriyor

Postgres, her update'te yeni bir satır sürümü yazan çok sürümlü eşzamanlılık kontrolü (MVCC) kullanıyor. Bir queue özünde sürekli değişen bir tablodur: job'lar talep edilir, tamamlanır ve yeniden denenir; her geçiş bir update daha demektir. Stripe'ın eski bir staff engineer'ı olan Brandur Leach, Postgres'teki transactionally staged job drains üzerine yazdığı makalesinde sonuçları belgelemiş; tablo şişmesini, index parçalanmasını ve ar yetişemeyen bir autovacuum sürecini anlatmış. Gunnar Morling da 3 Kasım 2025 tarihli "'You Don't Need Kafka, Just Use Postgres' Considered Harmful" başlıklı analizinde benzer bir sonuca vararak, uzun süren consumer transaction'larının kaçınılmaz olarak MVCC şişmesine ve vacuum değişim hızına karşı yarışı kaybedene kadar write-ahead log birikimine yol açtığını savunuyor. Başka bir deyişle, queue içinde yaşadığı veritabanını yavaş yavaş yıpratıyor.

Üretilen iş (throughput) tavanı

dev.to yazısı ayrıca 15 Mayıs 2023 tarihli benchmark rakamlarına da değiniyor; buna göre Postgres tabanlı bir queue, 1KB payload'larla saniyede yaklaşık 660 mesajda ve 38ms'lik P95 publish gecikmesinde tavan yapıyor. Aynı test ortamında RabbitMQ saniyede 25.000 mesaj işleyerek yaklaşık kırk kat daha yüksek bir üretilen iş sağlıyor. Managed servisler farkı daha da açıyor: standart Amazon SQS pratik bir tavan olmadan çok yüksek üretilen iş sunarken, FIFO SQS saniyede 3.000 mesaja kadar tam olarak bir kez işleme (exactly-once) sağlıyor; batch kullanıldığında bu 30.000'e çıkıyor. Yazarın vurguladığı nokta şu: operasyonel karmaşıklıktan kaçınan ekipler, sıkıcı bir cloud queue üretim trafiğinde çok daha yukarı ölçeklenirken, sert bir tavana sahip bir araç seçiyor.

Sizi gece 3'te uyandıran hata modu

Yazının merkezindeki uyarı hata eşleşmesi (failure coupling) ile ilgili. Yazı, 17 Aralık 2021 tarihli bir AWS Architecture Blog gönderisine atıf yapıyor; bu gönderi, duran bir teslimat sürecinin veritabanı üzerinde backpressure oluşturarak yükselen arızalardan oluşan bir geri besleme döngüsü yarattığını anlatıyordu. Queue ve veritabanı aynı sistem olduğunda sonuçlar katlanıyor: queue'nun çökmesi uygulamayı da birlikte götürüyor, çıldıran veritabanı queue'nun toparlanmasını engelliyor ve her worker yeniden denemesi ikisini de daha da kötüleştiriyor. İkinci, daha sessiz bir baskı noktası ise bağlantılar. Postgres her bağlantı için bir OS süreci başlatıyor ve sürekli olarak job'ları poll eden, talep eden ve güncelleyen çok sayıda worker node'u, havuzu tüketebilecek bir bağlantı çalkantısı yaratıyor ve kullanıcıya dönük sorguları slot'lar için job runner'larla rekabet etmek zorunda bırakıyor.

Desenin makul olduğu durumlar

Yazar yaklaşımı tamamen dışlamıyor. Küçük iç görevler ve ara sıra yapılan background job'lar için makul bir tercih ve SKIP LOCKED düşük hacimde zarif bir ilkel olmaya devam ediyor. Tuzağa düşmek, düşük hacimde gösterilen bir şeyin üretim trafiği altında birebir aynı davranacağını varsaymak. Yazı net bir teşhis sunuyor: queue'nuzun çökmesi veritabanınızı da birlikte götürüyorsa, bir kısayol inşa etmemişsininizdir; tek bir hata noktası inşa etmişsinizdir.

Neden önemli

Yazı, popüler bir mimari basitleştirmeyi bedava bir kazanç değil, bir risk kararı olarak yeniden çerçeveliyor. Queue'yu primary veritabanına bağlamak, job üretilen işini veritabanı sağlığına bağlayıp worker takılmalarını müşteriye dönük olaylara çeviriyor ve depolama motorunun kendisiyle savaşan update ağırlıklı bir çalkantı ekliyor. Job hacmi yavaş yavaş artan ekipler için pratik çıkarım, eşitliği varsaymadan önce ölçmek: özel broker'lar ve managed queue'lar belli bir operasyonel yük getiriyor ama hata alanlarını ayrıştırıyorlar, vacuum baskısını ortadan kaldırıyorlar ve Postgres-as-a-queue yaklaşımının sunmadığı bir üretilen iş sunuyorlar.