Hatchet – Postgres tabanlı iş orkestrasyonu platformu

• Postgres tabanlı büyük ölçekli arka plan işleme platformu açık kaynaklıdır
• Dağıtık iş kuyruğu (Distributed Task Queue) ve iş akışı orkestrasyonu platformu
• Karmaşık iş akışları, hata kurtarma, zamanlama, olay tabanlı tetikleyiciler ve gerçek zamanlı izlemeyi destekler
• Python, Go, TypeScript SDK’ları sunar
• MIT lisansı ile sunulur; self-hosting ve bulut sürümleri mevcuttur

Başlıca özelliklerin özeti

• Kuyruk yönetimi

  • Postgres tabanlı dayanıklı kuyruk sistemi
    • Anahtar tabanlı kuyruklama (adil iş dağıtımı sağlar)
    • Hız sınırlama (Rate limiting)
    • Sticky Assignment ve Worker Affinity
  • İş dağıtımı, yeniden deneme ve hata bildirimlerini otomatik yönetir
  • Python / TypeScript / Go örnekleri sunar

• İş orkestrasyonu

  • DAG tabanlı iş akışı oluşturma
    • Koşul tabanlı yürütme (ör. sleep, olay tabanlı tetikleyiciler, üst işin çıktı değerine göre koşullu çalıştırma vb.)
    • Karmaşık dallanma mantığını işleyebilir
  • İşler arası bağımlılık tanımlama, birden fazla işi paralel çalıştırma
  • Durable task ile ara sonuçların saklanması ve kurtarılması desteklenir
    • Dayanıklı fonksiyon yürütme: Hata durumunda ara durumu önbelleğe alır ve yeniden çalıştırmayla geri yükler
    • Durable Sleep ve Durable Events de desteklenir

• Akış kontrolü (Flow Control)

  • Kullanıcı bazında eşzamanlılık sınırı
  • Genel ve dinamik hız sınırlama (Rate Limiting)
  • Stratejik iş dağıtımıyla sistem kararlılığı sağlar

• İş zamanlama

  • Cron işleri, zamanlanmış çalıştırma, durable sleep desteği
  • Örn: her gün gece yarısı çalıştırma, belirli bir saate planlama, tanımlı süre bekleme vb.

• İş yönlendirme

  • Sticky Assignment: işi aynı worker’a sabitleme
  • Worker Affinity: en uygun worker’ı seçme mantığı uygular

• Olay tabanlı tetikleyiciler

  • Harici olay alındıktan sonra işleri çalıştırabilir
  • Olay/sleep koşulları birleştirilebilir

• Gerçek zamanlı web arayüzü

  • Gerçek zamanlı dashboard ve izleme
  • İş loglarını görüntüleme, bildirim ayarları (Slack/e-posta)

Hatchet ne zaman tercih edilmeli?

• ✅ DAG tabanlı iş akışı kurgusu gerektiğinde
• ✅ İş başarısız olduğunda yeniden deneme ve durumun korunması önemli olduğunda
• ✅ Çok kullanıcılı uygulamalarda işlerin dağıtık şekilde işlenmesi gerektiğinde
• ❌ Hızlı kurulabilen basit bir kuyruk yeterliyse (Celery/BullMQ vb. önerilir)
• ❌ Çeşitli veri bağlayıcılarıyla entegrasyon kritikse (Airflow/Prefect vb. önerilir)

Karşılaştırma: Hatchet ve diğer çözümler

• Hatchet vs Temporal

  • Hatchet, kuyruk + DAG + Durable Execution bileşiminin tamamını destekler
  • Temporal, Durable Execution için optimize edilmiştir
  • Hatchet’te self-hosting daha kolaydır (yalnızca Postgres gerekir)

• Hatchet vs BullMQ / Celery

  • Hatchet, iş geçmişi saklama + UI görselleştirme + yerleşik orkestrasyon sunar
  • BullMQ/Celery hafif kuyruk kütüphaneleridir ancak izleme özellikleri sınırlıdır

• Hatchet vs Airflow / Prefect

  • Hatchet, yüksek hızlı yürütme, düşük gecikme, kendi worker yönetimi sunar
  • Airflow/Prefect veri hattı odaklıdır ve entegrasyon bağlayıcılarında güçlüdür

Özet

• Hatchet, yalnızca Postgres ile çalışan modern bir dağıtık işleme platformudur
• Durable, Observable ve Composable iş sistemleri tek bir araçla kurulabilir
• Hem bulut hem de self-hosting desteklenir; Python/Go/TypeScript ile kolayca entegre edilebilir

[halfenif]

2 saat test edip yazıyorum.

• Zaten bir MQ kurduğum için, Postgres tabanlı yeni bir şey mi diye düşünüp test ettim ama Rabbit gerektiğini görünce biraz hayal kırıklığına uğradım
• k8s bakış açısından olmadığı için docker-compose.yaml dosyasını podman(+Arch) üzerinde çalıştırdım
• Postgres'i ayrı kullanmak istediğim için biraz daha fazla yapılandırma yapmam gerekti, ancak en sonunda SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER: Invalid certificate verification context hatasıyla karşılaşınca durdum
• Arada bir şeyler yanlış giderse Postgres veritabanını drop edip yeniden başlamak gerekiyordu
• Her seferinde API Key oluşturmak gerekiyor, ancak Web arayüzünde Key'in tamamı görünmediği için geliştirici araçlarını kullanarak çıkarmak zorunda kaldım.

[GN⁺]

Hacker News görüşleri

• Procrastinate veya Chancy gibi diğer pg tabanlı Python iş çalıştırıcılarıyla karşılaştırıldığında farkının ne olduğunu merak ediyorum

• Oldukça ilgi çekici görünüyor

  • FOR UPDATE SKIP LOCKED yaklaşımının 25k sorgu/sn düzeyine ölçeklenmediği söylenirken, sınırın tam olarak hangi noktada ortaya çıktığını merak ediyorum
  • Arabelleğe alınmış okuma ve yazma ile tüm büyük tabloların ID sütununa geçirilmesi konusunu merak ediyorum
  • Bunların, FOR UPDATE SKIP LOCKED yaklaşımını ihtiyaçlara uygun şekilde ölçeklendiren çözümün bir parçası olup olmadığını merak ediyorum

• Kuyruk işlemlerinin (işi kuyruğa ekleme ve tamamlandı olarak işaretleme) iş mantığımla aynı transaction içinde gerçekleşip gerçekleşmediğini merak ediyorum

  • Bence veritabanı tabanlı kuyrukların temel özelliği bu
  • Retry mantığını basitleştiriyor
  • İşin yürütülmesi sırasında da aynı sorun ortaya çıkabilir
  • Bu noktada belki SQS kullanmak daha iyi olabilir

• Olay/iş akışı tabanlı bir uygulama tasarlıyorum ve bu çözüm oldukça umut verici görünüyor

  • Temporal'ı da değerlendirdim ama tam olarak uygun olduğunu hissetmedim
  • Açık kaynak lisansı, uygulama tasarımı konusunda güven veriyor
  • CEL benzeri koşul ifadeleri arıyordum

• Hatchet mimarisindeki altı iyileştirme sayesinde performans her açıdan artmış

  • Zaman serisi tabloları için aralık tabanlı partitioning
  • İş event'leri için hash tabanlı partitioning
  • İzleme tabloları ile kuyruğun ayrılması
  • Arabelleğe alınmış okuma ve yazma
  • Tüm büyük tabloların ID sütununa geçirilmesi
  • Postgres trigger'larının yoğun kullanımı
  • Kılavuzu okursanız şaşırtıcı şeyler yapabilirsiniz

• README, dark mode kullanan kullanıcıların daha fazla olduğunu varsayıyor

  • Logo beyaz olduğu için dark mode yoksa görünmüyor
  • GitHub istatistiklerine bakmak ilginç olurdu

• Postgres'i message queue olarak kullanırken büyük payload'ları (50MB üzeri) işleme sorunuyla karşılaştım

  • Çözüm olarak unlogged tablolar ve düzenli full vacuum kullanmıştım
  • Postgres uzmanı değilim ama bu sorunu çözüp çözmediklerini merak ediyorum

• Belgeleri 15 dakika gözden geçirdikten sonra geri bildirim veriyorum

  • Light mode, açık kaynak, logging ve DX arayüzü güzel
  • Hello World örneğini gerçek bir senaryoyla değiştirmek daha iyi olurdu
  • Çok aşamalı işler içeren bir iş akışının kodu sezgisel görünmüyor
  • Hatchet'in düşünme biçimine, kalıplarına ve terminolojisine alışmak gerekiyor
  • Müşteriler için kolaylaştırma yönünde yeterince çaba yokmuş gibi görünüyor
  • Mühendislik yazıları anlamlı ama müşteriler cloud altyapısıyla ilgilenmiyor
  • İş akışı pazarında çok fazla seçenek olduğu için sonunda bir kez daha yeniden yazmaları veya pivot etmeleri olası görünüyor
  • Otomasyon yolculuğuna odaklanmaları ve insanların kolayca alıp yapılandırabilmesini sağlamaları gerekiyor
  • İş akışlarını JSON olarak serialize etmek zor
  • Hatchet iş akışlarının başka bir şirkete kolayca taşınabilmesi gerekir

• v1 çıkışını kutlarım

  • Hatchet'i neredeyse 1 yıldır kullanıyorum ve 6 ay önce production'a aldım
  • Açık kaynak desteği ve hızlı başlangıç harika
  • Sisteme harcanan mühendislik emeği açıkça görülüyor

• İlk izlenimim olumlu, çıkışı kutlarım

  • Birkaç sorum var
  • Kalıcı işleri destekleyip desteklemediğini merak ediyorum
  • İş girdileri ve çıktılarının nerede saklandığını merak ediyorum
  • PostgreSQL instance boyutu ve I/O metriklerine bakarak sistemin saniyede kaç işi işleyebileceğinin tahmin edilip edilemeyeceğini merak ediyorum
  • Çeşitli araçları değerlendiriyorum ve Hatchet'in nasıl bir his verdiğini anlamak istiyorum
  • Minimum boilerplate ile çalışabileceğim bir araç arıyorum