Postgres'ta dayanıklı iş akışları kurmak

• Dayanıklı (durable) iş akışları, yürütme durumunu veritabanına checkpoint alarak çökme sonrası son tamamlanan adımdan kurtarmayı sağlar
• Temporal, Airflow, AWS Step Functions tarzı harici orkestrasyon, merkezi bir orkestratör ve depo ekleyerek karmaşıklığı artırır
• Postgres tabanlı mimari, uygulama sunucularının iş akışı tablolarını poll etmesini ve adım çıktılarını doğrudan kaydetmesini sağlayarak kurtarmayı mümkün kılar
• Birden fazla sunucu, kilitler ve bütünlük kısıtları ile yinelenen yürütmeyi engeller; ölçeklenebilirlik, erişilebilirlik ve gözlemlenebilirlik sorunlarını Postgres çözümleriyle ele alır
• Tek bir Postgres, saniyede on binlerce iş akışına kadar dikey ölçeklenebilir; replikasyon, multi-AZ ve SQL analitiğinden doğrudan yararlanılabilir

---

Dayanıklı iş akışlarının temel modeli

• Dayanıklı iş akışları, program yürütülürken ilerleme durumunu düzenli aralıklarla checkpoint olarak veritabanına kaydederek, çökme veya hata sonrasında son tamamlanan adımdan kurtarmayı mümkün kılan bir yaklaşımdır
• Bunu, video oyunlarındaki kaydetme ve yükleme gibi, programın ilerlemesini düzenli olarak “kaydetmek” ve çökme sonrası son checkpoint'ten “yüklemek” şeklinde düşünebilirsiniz
• Yaygın uygulama biçimi, Temporal, Airflow, AWS Step Functions gibi harici orkestrasyon sistemleridir
• Harici orkestrasyonda dayanıklı program, birden çok adımdan oluşan bir iş akışı olarak yazılır ve yürütme merkezi bir orkestratör tarafından koordine edilir

Harici orkestrasyon nasıl çalışır

• İstemci bir iş akışı gönderdiğinde, orkestratör veri deposunda bir kayıt oluşturur ve yürütme için bunu bir workera dispatch eder
• Worker her adımı tamamladığında sonucu orkestratöre gönderir; orkestratör de bu çıktıyı veri deposuna checkpoint aldıktan sonra bir sonraki adımı dispatch eder
• Worker çöker veya hata verirse, orkestratör ilgili iş akışını başka bir workera yeniden dispatch eder ve son checkpoint alınan adımdan başlatır
• Bu yapı, iş akışı durumunu veritabanında saklama fikrinin üzerine ayrı bir orkestratör sunucusu ekleyerek karmaşıklığı artırır

Postgres'i orkestratör olarak kullanan mimari

• Dayanıklı iş akışlarının özü, program durumunu veritabanına checkpoint almaksa, ayrı bir orkestratör sunucusu olmadan veritabanının kendisini orkestratör olarak kullanmak daha basit ve verimlidir
• Postgres; yaygınlığı, ölçeklenebilirliği ve zengin ekosistemi sayesinde dayanıklı iş akışları kurmak için uygun bir seçenektir
• Postgres tabanlı dayanıklı iş akışı sistemlerinde uygulama sunucuları, merkezi orkestratörden geçmeden Postgres ile doğrudan iletişim kurarak iş akışlarını yürütür
• İstemci, çalıştırma talebini Postgres'teki iş akışı tablosuna bir kayıt ekleyerek gönderir; uygulama sunucuları da bu tabloyu poll ederek iş akışını dequeue edip çalıştırır
• Sunucular iş akışını yürütürken her adımın çıktısını Postgres'e checkpoint alır; çalışan sunucu çöker veya hata verirse başka bir sunucu iş akışını checkpoint'ten kurtarır

Merkezi orkestratör neden gereksiz hale gelir

• Uygulama sunucuları Postgres üzerinden koordine olabildiği için, merkezi bir orkestratörün iş akışlarını worker'lara dispatch etmesine gerek kalmaz
• Sunucular Postgres tablolarından iş akışlarını işbirliği içinde dequeue edebilir; lock clause gibi mekanizmalarla her iş akışının tam olarak bir worker tarafından dequeue edilmesi garanti edilebilir
• Adım çıktılarını checkpoint alma işlemi de orkestratör yerine doğrudan worker tarafından Postgres'e yazılır
• Birden fazla worker aynı iş akışını aynı anda çalıştırmaya kalkarsa, Postgres'in bütünlük kısıtları checkpoint anında yinelenen işi algılayıp geri çekilmelerini sağlayabilir
• Merkezi orkestratörü Postgres veya başka bir veritabanıyla değiştirmek; ölçeklenebilirlik, erişilebilirlik, gözlemlenebilirlik ve güvenlik gibi sorunların iyi bilinen Postgres-native çözümlerle ele alınmasına olanak verir

Ölçeklenebilirlik ve erişilebilirlik

• Veritabanı tabanlı dayanıklı iş akışı sistemlerinin ölçeklenebilirliği ve erişilebilirliği temelde altyapıdaki veritabanı tarafından belirlenir
• Worker sunucuları eklenerek yatay ölçekleme yapılabildiğinden, azami kapasite veritabanının iş akışlarını ne kadar hızlı işleyebildiğine bağlıdır
• Worker'lar birbirinin yerine geçebilir ve birbirlerinin durumunu kurtarabilir; bu yüzden altyapıdaki veritabanı erişilebilir olduğu sürece sistem de erişilebilir kalır
• Postgres kullanıldığında avantaj, ölçeklenebilirlik ve erişilebilirliğin uzun süredir çalışılmış problemler olması ve sağlam çözümlerin bulunmasıdır
• Tek bir Postgres sunucusu, saniyede on binlerce iş akışı işleyecek şekilde dikey ölçeklenebilir
• Daha fazla ölçek için CockroachDB gibi dağıtık Postgres veya sharding uygulanmış Postgres kullanılabilir
• Postgres, otomatik failover içeren streaming replication'ı destekler; yönetilen servisler ise varsayılan olarak multi-AZ dağıtım ve yüksek erişilebilirlik SLA'leri sunar
• Postgres'i büyük ölçekte çalıştırmak için onlarca yılda biriken mühendislik ve araştırma birikimi, dayanıklı iş akışlarının işletiminde de doğrudan kullanılabilir

Gözlemlenebilirlik

• Postgres tabanlı dayanıklı yürütmede iş akışları ve adımlar Postgres tablolarına checkpoint alındığı için, bu checkpoint'ler taranarak iş akışları gerçek zamanlı izlenebilir ve yürütme görselleştirilebilir
• Neredeyse tüm iş akışı gözlemlenebilirlik sorgularının SQL ile ifade edilebilmesi, Postgres'in güçlü yanlarından biridir
• Örneğin son bir ayda hata veren tüm iş akışlarını bulan sorgular gibi karmaşık filtreleme ve analiz işlemleri SQL ile deklaratif biçimde ifade edilebilir
• Bu, Postgres'in ilişkisel modeli ve onlarca yıllık sorgu optimizasyonu araştırmalarından yararlanıldığı için mümkündür
• Popüler harici orkestratörlerin kullandığı key-value store'lar gibi daha basit veri modellerine sahip birçok sistem, aynı düzeyde SQL tabanlı analiz desteği sunamaz
• İş akışı ve adım verilerini Postgres tablolarında saklayıp hızlı analitik sorgular için ek indeksler oluşturduğunuzda, dayanıklı yürütmede verimli gözlemlenebilirlik elde edebilirsiniz

Güvenilirlik ve güvenlik

• Harici orkestratör kullanan dayanıklı yürütmede, orkestratör ve onun veri deposu birlikte tek hata noktası haline gelir
• Orkestratör ve veri deposu iş akışı yürütmesini doğrudan koordine ettiğinden, bunlardan biri bile devre dışı kalırsa tüm uygulama kullanılamaz hale gelir
• Bunlar iş akışı ve adım checkpoint'lerini işleyip depoladıkları için hassas uygulama verilerine erişebilir; dolayısıyla hassas altyapı gibi hardening, erişim kontrolü ve denetim gerektirirler
• Postgres tabanlı dayanıklı yürütmede tek hata noktası Postgres'in kendisidir; tüm iş akışı verileri doğrudan Postgres'te tutulur ve başka sistemlerden geçmez
• Uygulama zaten Postgres'e bağımlıysa, dayanıklı yürütme eklemek yeni bir hata noktası oluşturmaz ve korunması gereken yeni bir saldırı yüzeyi de yaratmaz
• Veritabanı zaten çekirdek altyapı olduğundan, orkestrasyon için yeni bir çekirdek altyapı eklemek yerine mevcut veritabanını yeniden kullanmak daha mantıklıdır

Daha fazlasını keşfedin

• Quickstart
• GitHub
• Discord community

[GN⁺]

Hacker News yorumları

• Armin Ronacher’in absurd projesi, Postgres için kalıcı iş akışları gerçekleştirimidir
  https://lucumr.pocoo.org/2025/11/3/absurd-workflows/
  https://github.com/earendil-works/absurd
  https://earendil-works.github.io/absurd/
  Kendim kullanmadım ama diğer seçeneklerle karşılaştırmaya değer görünüyor

  • Çok yüksek işlem hacmi gerekmiyorsa, absurd ve onun Rust türevi uygulaması durable, istemci tarafını son derece basit tutmak için iyi seçenekler gibi görünüyor
    Hafifler; bu yüzden bir kodlama ajanı tüm yapıyı zihninde kolayca tutabilir ve gerekirse durum sorgularla incelenebilir

• dbos.dev, restate.dev ve cf workflows kullanıyorum; Agents.md dosyamızda şunlar yazıyor
  Restate.dev, northflank’in ödeme entegrasyonunda kullanılıyor. cf workflows’tan daha hızlı, Cloudflare’a ve onun kesintilerine bağımlı değil ve self-host edilebildiği için vendor lock-in yaratmıyor
  Cloudflare workflows, CSV/PDF rapor üretimi gibi önemi daha düşük işler için kullanılıyor. Çünkü çok ucuz
  DBOS.dev, Postgres transaction’larıyla birleşik atomik mesajlaşma gerektiği için %100 güvenilirlik/kalıcılık isteyen iş akışlarında kullanılıyor. Örneğin materialized row doldurma veya satıcıya önemli e-posta/push gönderme
  DBOS ve Restate yüzeyde benzer görünüyor ama Restate’in merkezi bir “orchestrator” gerektirmesi nedeniyle artıları ve eksileri var; ayrıca cf/vercel’in serverless worker’larıyla birlikte kurmak daha kolay oluyor
  Ayrıca VirtualObject sunduğu için, Cloudflare’ın tek iş parçacıklı DurableObject’ine vendor lock-in içermeyen açık kaynak bir alternatif olarak da fena değil
  DBOS’un özellikle parladığı iki nokta var. 1) dbos.enqueue_workflow ile iş mantığıyla aynı DB transaction’ı içinde atomik mesajlaşma yapılabiliyor. Bu kısım çoğu çözümde genellikle en zayıf halka oluyor; iş mantığının çalıştığı aynı transaction içinde bunu atomik ve kalıcı şekilde halletmek karmaşıklığı ciddi ölçüde azaltıyor
  2) DBOS iş akışı durumunu DB’de tuttuğu için, metabase/looker ile gözlemlenebilirlik panoları oluşturmak kolay olur gibi görünüyor. Restate’in de rocksdb instance’ını açığa çıkarıp metabase’e bağlanabilmesi güzel olurdu

  • Şema güncellemeleri nasıl ele alınıyor merak ediyorum. İşler migrate mi ediliyor, yoksa worker deployment’ı belirli bir şekilde mi yönetiliyor?

• DBOS ve Temporal kullananların pratikte nasıl hissettirdiğini merak ediyorum.
  Daha önce Temporal kullandım ve oldukça iyi çalışıyordu, ancak istek payload’u veya event boyutu sınırları yüzünden çözüm geliştirirken rahatsız olduğum zamanlar oldu.
  İyi mühendislik pratiklerini zorunlu kılması avantaj, ama CSV dosyası 2MB’tan büyük diye onu S3’e yükleyip bağlantıyı ilettikten sonra workflow içinde tekrar indiren özel mantığı her zaman kullanmak istemiyorum.
  DBOS deneyimi nasıl, operasyonel karmaşıklık veya özellik eşdeğerliği gibi açılardan Temporal ile nasıl karşılaştırılıyor merak ediyorum.

  • DBOS kullanmadım ama şu anki ve önceki işimde Temporal kullandım; toplamda yaklaşık 1,5 yıllık deneyimim var.
    Evde de zaman hassasiyeti çok yüksek olmayan home automation işlerini yürütmek için kullanıyorum. Workflow gecikmesi çok kötü değil, ama evdeki hareket algılama event’leri gibi anında tepki gerektiren tetikleyiciler için kullanmazdım; belli bir süre hareketsizlikten sonra bir şeyi kapatan timeout’lar içinse uygun.
    VPC veya Kubernetes cluster içinde Temporal’ın önüne ince bir REST API koyma yaklaşımını oldukça seviyorum. Böylece event tabanlı tetikleyicilerin Temporal kimlik doğrulaması ya da workflow durum kontrolüyle uğraşması gerekmiyor ve event’leri mümkün olduğunca mantıksız tutmaya yardımcı oluyor.
    Örneğin bir DB trigger’ı doğrudan çalışır ya da bir event’i queue’ya koyar ve handler gerekli event ayrıntılarıyla ince REST API’yi çağırır. REST API bunun bir workflow başlatıp başlatmayacağına, mevcut bir workflow’a signal gönderip göndermeyeceğine ya da yok sayıp saymayacağına karar verebilir. Desen duruma göre değişir ama ben sık sık SignalWithStart kullanıyorum; ya da başlatmaya değmezse ve mevcut workflow da yoksa doğrudan düşürüyorum.
    Ayrıca tek bir nesnenin yaşam döngüsünde birbirinden bağımsız davranışları orkestre etmeniz gerektiğinde ebeveyn/çocuk workflow özelliği çok kullanışlı ve dış etkenler nesnenin ilerleme yolunu değiştirdiğinde iptal edilebilir olması da güzel.
    Uzun ve muğlak söylemek gerekirse, çok güçlü, kullanımı kolay ve yaşam döngüsü mantığını API’nin dışına çıkarmakta çok yardımcı. API’nin içine koyarsanız teknik borç kolay birikir ve yönetim kırılganlaşır. Kolay görünen yerlere mantık atıp sonradan gizli tuzaklara dönüşmesindense, iyi pratikleri takip etmeye zorlaması konusunda katılıyorum.
  • Temporal bana aşırı karmaşık geldi ama dediğin gibi en iyi tarafı iyi mühendislik pratiklerini zorunlu kılması.
    Ama Cloud ürününü deneyince fiyatı karşısında şoke oldum. Henüz production’a çıkmadan 1.000 dolarlık ücretsiz krediyi bitirdim. Local Temporal’ı da kendim işletmek istemedim.
    Bence en iyisi mimarideki fikirleri alıp Postgres üzerinde kendin uygulamak.
  • Büyük payload sorununu çözmek için external storage yaklaşımını yeni çıkardık.
    Ondan %100 memnun değilim. Temel bir parçadan çok sonradan eklenmiş gibi duruyor ve hâlâ erken sürüm. Yine de artık pratikte çözülmüş sayılabilir.
  • Büyük ölçekli on-prem Temporal kurulumu işletiyorum; bu hesap da fark edilmesin diye geçici bir hesap.
    1 yılı aşkın production deneyimime göre Temporal kötü tasarlanmış, yavaş ve altyapı açısından akıl dışı derecede ağır.
    Önemsiz olmayan işler, örneğin workflow başına 200’den fazla event ve aynı anda birkaç yüz tanesi tüm gün çalışıyorsa, altyapı maliyetine milyonlarca dolar harcayabilirsiniz ve yine de iyi olmaz.
    Kendi benchmark’larımızı çalıştırınca rakamlar berbat çıkıyor.
    Satış ekibi de gerçekten korkunç ve çaresiz görünüyor.
    Geliştirici açısından bakınca SDK’leri oldukça iyi.
    nexus’a kilitlenmeyin ve satış ekibi ararsa mutlaka hukuk ekibini de görüşmeye alın.
  • Biz yapay zeka tarafından üretilen workflow’lar ve video dosyası işleme için dbos kullanıyoruz.
    Celery’den nasıl migrate edeceğimizi anlamak zaman aldı ama bizim kullanım senaryomuzda buna değdi.

• Conductor OSS de bunu oldukça iyi yapıyor https://docs.conductor-oss.org/devguide/ai/index.html
  https://github.com/agentspan-ai/agentspan özünde Conductor için bir agent SDK katmanı; langgraph, OpenAI, vercel ve ADK agent’larını kod değişikliği olmadan dayanıklı hale getirip orkestrasyon ekleyebiliyor.

  • Biz production’da queue için Redis kullanıyoruz ama kullanıcılar arasında queue olarak Postgres ve MySQL kullananları da gördüm.

• Veri deposu, durum makinesi, geçerli durum kısıtları ve geçerli durumlar arasında geçiş yapan mantığı ayırmak yerine, bunları uygulama durumunun bir tür çekirdeğinde birleştirebilsek güzel olurdu.
  Açıkçası Postgres’te bunun için zaten çok fazla yetenek var, ama uygulama veya ürün düzeyinde, uygulamanın geçebileceği kanıtlanabilir durumlar kümesini sunan ve bunu istemcilere faydalı olacak şekilde otomatik açığa çıkaran net bir tablo hâlâ görmüyorum. Örneğin bu kullanıcı bu gönderiyi beğenebilir ama düzenleyemez gibi.
  Bana colored Petri net gibi görünüyor ama veritabanının başarılı sınırları açıkça tanımlı olduğu kadar basit bir uygulama durumu paradigması henüz görünmüyor.

  • Temporal.io query, signal ve update özellikleriyle buna bir ölçüde yaklaşıyor.
    Ama bunun tam bir bütünleşme olup olmadığından emin değilim.
  • Bunun gibi girişimler oldu ama bin satırlık stored procedure gerçekten kâbus.
  • Bu convex.dev veya https://spacetimedb.com/ gibi geliyor. İkisini de bizzat kullanmıyorum.

• DBOS Rust desteklemediği için buna benzer çok minimal bir Rust sürümünü https://github.com/tensorzero/durable içinde uyguladım.
  Oldukça kararlı ve ölçeklenebilir oldu ama tabii ki SQL implementasyonu konusunda çok dikkatli olmak gerekiyor. Buradaki okuyucular için ilgi çekici olabilir diye düşündüm.

  • Bu da yakında open source olacak.
    https://flawless.dev/

• Kavramı tamamen anlıyor ve buna katılıyorum. Bu tür bir dayanıklılığı bir workflow sistemine koymanın harika bir yolu.
  Ama oyuncu beynimle buna “büyük ölçekli save scumming” demek istiyorum. Zaten birçok kişi bu yaklaşımın işe yaradığını biliyor, ancak bunu soyut bilgisayar bilimi kavramlarıyla ilişkilendirmemiş olabilir.
  Sağlamlığı artırmanın bir başka stratejisi de workflow’u idempotent işlemlerden oluşturmak. Workflow durumunun yedeklenemeyecek kadar büyük olduğu durumlarda faydalı olabilir. Bunun yerine işi baştan yeniden çalıştırırsanız, tekrar ilerleme kaydedilen noktaya kadar her şey no-op olur

• Araç kutusunda Postgres olduğu sürece az araçla yapılabilecek şeyler beni şaşırtmaya devam ediyor.
  Kısa süre önce bir dağıtık kuyruk geliştirdim; gerçekten çok iyi çalışıyor, benchmark sonuçları da iyi ve yarış durumu ya da çakışma da yok. Worker’ların güvenli şekilde yarışabilmesi için SKIP LOCKED kullandım.
  Birden fazla node’daki worker’ların çakışmadan kaçınması gerekiyorsa oturum kapsamlı mutex, yani pg advisory lock, da kullanılabilir

  • Zaten bu gibi durumlarda tercih edilen şey advisory lock oluyor. Çok fazla SELECT FOR UPDATE tutarsanız iyi ölçeklenmiyor.
    Düzeltme: tekrar kontrol edince artık tavsiyenin tersine döndüğünü gördüm gibi
  • Kaydı actor ID ile rezerve etmek yeterli

• Rails’te veritabanı tabanlı birkaç iş backend’i var, ancak teamül gereği işler her zaman tek bir şey yapmalı ve mümkünse çok kısa sürmeli.
  Bu yüzden workflow oluşturmak biraz zorlama hale geliyor. İlk işin son satırında ikinci işi kuyruğa koyuyor, ikinci işin son satırında da üçüncü işi kuyruğa koyuyorsunuz.
  İş backend’i bunları birbirine bağlı bir workflow olarak göstermiyor, bağımsız işler olarak ele alıyor; workflow’u üst düzeyde anlamaya çalıştığınızda da birden fazla iş sınıfını okumanız gerekiyor.
  Rails kısa süre önce iş içinde adım adım checkpoint alıp devam etmeyi sağlayan continuable kavramını tanıttı, ama işleri tek sorumluluklu tutma teamülü hâlâ çok güçlü olduğu için bunu gerçek workflow’larda kullanmak garip kalıyor.
  Başkaları da buna benzer şeyler yaşadı mı, bir çözüm buldu mu merak ediyorum

• Bu harika bir pattern. Mümkün olduğunca çok şeyi veritabanının içinde yapmak iyi olur.
  Harici Spanner change streams sağlıyor. Dahili Spanner ise farklı; bunun başlıca nedeni bazı durumlarda aşırı ölçek gereksinimleri olması, ama biraz da “zaten iyi çalışıyor” ve “rastgele change stream’ler korkutucu” düşüncelerinin karışımı.
  Dahili Spanner, herhangi bir transaction’ın kuyruk girdisi yazmasına izin veriyor. Burada kuyruk, kabaca özel zaman farkındalığı olan bir tablo. Teslimat zamanlanabiliyor ve girdiler kuyruktan handler’a push ediliyor; handler da dequeue transaction’ı içinde DB write yapabiliyor. Üstelik aynı ölçeklenebilirliğin tamamı korunuyor.