River: Go और Postgres के लिए एक तेज़, मज़बूत job queue

मूल लेख ↗ Hacker News चर्चा ↗

River नाम की एक नई Go library PostgreSQL को एक transactional job queue के रूप में उपयोग करने का प्रस्ताव रखती है, जिसमें job creation को उसी database transactions से जोड़ा जाता है जो application data को बदलती हैं। समर्थकों का तर्क है कि यह “single dependency” तरीका architecture को सरल बनाता है, atomic enqueueing के ज़रिए correctness बेहतर करता है, और अधिकांश workloads के लिए पर्याप्त scale करता है, जैसा कि Oban जैसे समान systems से साबित होता है। आलोचकों का कहना है कि relational databases उच्च-scale queues के लिए खराब होते हैं और वे dedicated services या HTTP-based task systems को तरजीह देते हैं, साथ ही performance, long-running jobs, और Redis, Kafka, Temporal, या cloud task queues जैसे tools के मुकाबले trade-offs को लेकर चिंता जताते हैं।

डिज़ाइन: Postgres-समर्थित, transactional job queue

  • मूल विचार: jobs को business data के साथ उसी DB transaction के भीतर enqueue किया जाता है (“transactional outbox” शैली)।
  • इससे job creation domain changes के साथ atomic रहती है: या तो दोनों commit होते हैं, या कोई नहीं।
  • Jobs अलग-अलग processes द्वारा worked होती हैं; transaction केवल enqueueing के लिए है, execution के लिए नहीं।
  • ScheduledAt विकल्प के माध्यम से scheduled (delayed) jobs के लिए समर्थन मौजूद है, हालांकि docs अभी भी तैयार किए जा रहे हैं।

Queue के रूप में RDBMS: फायदे और नुकसान

  • समर्थक:
    • मज़बूत correctness guarantees, सरल mental model, और अगर Postgres पहले से उपयोग में है तो कम moving parts।
    • अधिकांश systems के लिए पर्याप्त throughput; अन्य ecosystems के उदाहरण प्रति सेकंड दसियों हज़ार jobs दिखाते हैं।
    • कई छोटे/मध्यम apps के लिए Redis/RabbitMQ/Kafka जोड़ने की तुलना में operations आसान।
  • संदेहवादी:
    • “Databases make poor queues” एक सामान्य धारणा बनी हुई है, जिसमें scalability, bloat, और long-running job concerns का हवाला दिया जाता है।
    • कुछ लोग अपने पिछले अनुभव के आधार पर कहते हैं कि वे job queue के रूप में RDBMS का “कभी” उपयोग नहीं करेंगे।

Implementation Details और Patterns

  • सामान्य pattern: jobs को workers के बीच सुरक्षित रूप से lease करने के लिए SELECT … FOR UPDATE SKIP LOCKED (या इसके variants) का उपयोग।
  • सुझावों में शामिल हैं:
    • foreign-key inserts को block होने से बचाने के लिए FOR NO KEY UPDATE का उपयोग।
    • बेहतर throughput के लिए jobs table को partition करना, per-tenant sequencing, और leases के माध्यम से bulk-processing।
  • Workers को जगाने के लिए Postgres NOTIFY का उपयोग किया जा सकता है, लेकिन overhead और PgBouncer जैसे poolers के साथ incompatibility को लेकर चिंता है।
  • कुछ features विकास में हैं या अनुरोधित हैं: UI dashboard, job completion notifications, richer workflow support।

अन्य systems के साथ तुलना

  • अन्य भाषाओं में संबंधित Postgres job queues (जैसे well-known Elixir और JS libraries) को prior art और इस model के काम करने के प्रमाण के रूप में उद्धृत किया गया है।
  • जिन alternatives पर चर्चा हुई:
    • HTTP-based queues (GCP Tasks, SQS-style) को simplicity के लिए सराहा गया, लेकिन transactional correctness issues और timeout limits के लिए आलोचना की गई।
    • Kafka- या NATS-based approaches, Temporal-like workflow engines, और pure-SQL queues (जैसे PGMQ) को अलग-अलग trade-off points के रूप में उल्लेख किया गया।

Project Direction, Licensing, और Attribution

  • कुछ लोग commercial बनाम purely open-source लक्ष्यों के बारे में सोचते हैं, और क्या समान Go queues को “join forces” करना चाहिए।
  • Go library के लिए LGPLv3 license पर static linking के कारण सवाल उठते हैं; maintainers स्वीकार करते हैं कि इसे स्पष्ट करने या समायोजित करने की आवश्यकता है।
  • इस बात पर बहस है कि डिज़ाइन कितना existing Postgres-based job systems से प्रेरित था, और स्पष्ट attribution के लिए calls किए गए हैं।