Show HN: Hatchet – ओपन-सोर्स वितरित टास्क क्यू

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

आर्किटेक्चर और स्थायित्व मॉडल

  • टास्क पूर्वनिर्धारित workflows द्वारा समर्थित होते हैं, जिनके steps और inputs/outputs Postgres में persist किए जाते हैं।
  • Engine components Postgres को poll करते हैं, long‑lived gRPC connections के माध्यम से work assign करते हैं, और DB में timeouts तथा retries को track करते हैं।
  • Durable execution “at‑least once” है: stored inputs के साथ steps को replay किया जा सकता है; idempotent task design की सिफारिश की जाती है।
  • Redis-based locks की जरूरत नहीं; Postgres core durability और coordination layer है।

Worker व्यवहार और failure semantics

  • Workers हर कुछ सेकंड में heartbeat भेजते हैं; यदि लगभग 60s तक inactive रहें, तो tasks फिर से assign कर दिए जाते हैं (यदि retries बाकी हों)।
  • Cancellation signals भेजे जाते हैं, लेकिन उनका deliver होना guaranteed नहीं है; यदि workers cancels ignore करें या reassignment के बाद वापस आ जाएँ, तो duplicate executions संभव हैं।
  • इसे एक edge case माना गया है, जिसके लिए alerting और बेहतर monitoring की आवश्यकता है।

Workflows, DAGs, और सीमाएँ

  • Workflows पहले से DAGs के रूप में घोषित किए जाते हैं; इससे procedural code की तुलना में visualization, versioning, और multi-step debugging सरल हो जाता है।
  • Tradeoffs: एक single task के भीतर कोई try/catch नहीं, और अभी “await futures & gather later” जैसा सरल model भी नहीं है। Procedural workflows roadmap में हैं।
  • Child workflows को steps से trigger किया जा सकता है; array return value के आधार पर fan-out पर विचार किया जा रहा है।
  • Runtime पर dynamic DAG mutation को फिलहाल समर्थित बताया नहीं गया है।

अन्य tools से तुलना

  • इसे Celery/Redis/RabbitMQ के विकल्प के रूप में पेश किया गया है, अधिक observability और UI के साथ, तथा conceptually Temporal/Cadence जैसा लेकिन ऑपरेट करने में सरल।
  • pg-boss/River/Graphile Worker से यह अलग है क्योंकि यह pure library नहीं बल्कि एक separate service + UI है, और workflow semantics तथा worker pools जोड़ता है।
  • Windmill/Inngest से तुलना में: Postgres-based workflow engine जैसा; Hatchet अधिक संकीर्ण है (task queue + workflows) और MIT-licensed है।

Dependencies और infra choices

  • अभी Postgres के साथ कुछ pub/sub के लिए RabbitMQ का उपयोग होता है; maintainers इसे Postgres LISTEN/NOTIFY या समान किसी चीज़ पर ले जाना चाहते हैं, लेकिन connection poolers और replay से जुड़ी जटिलताओं का उल्लेख करते हैं।
  • Thread में कुछ लोग कहते हैं कि RabbitMQ सस्ता और भरोसेमंद है; अन्य Postgres के आसपास moving parts कम रखना पसंद करते हैं।

Self-hosting, cloud, pricing, licensing

  • Self-hosting guide उपलब्ध है; मुख्य बात highly available ingestion service और managed Postgres with PITR है।
  • Cloud offering early access में है; pricing अभी प्रकाशित नहीं हुई है।
  • Project पूरी तरह MIT है; revenue hosted Hatchet Cloud और संभवतः enterprise support से अपेक्षित है।
  • Hyperscaler “lift-and-serve” risk की awareness है; इसके बावजूद MIT चुना गया है।

Scheduling, delayed jobs, और use cases

  • Cron-based scheduling Go cron library के माध्यम से उपलब्ध है; one-time/delayed scheduling एक basic form में मौजूद है और इसे DB-driven तथा scalable बनाने के लिए refactor किया जा रहा है।
  • कुछ long-horizon reminder/notification use cases (जैसे healthcare follow-ups) अभी अच्छी तरह समर्थित नहीं हैं, लेकिन वे target हैं।
  • Hatchet AI-specific नहीं है, लेकिन इसे GenAI pipelines और अन्य multi-step, resource-bound workflows के लिए उपयुक्त बताया गया है।

Performance और observability

  • Reported average start latency: first step के लिए ~50 ms, subsequent steps के लिए ~25 ms load tests में; स्वीकार किया गया कि यह raw message queues से धीमा है, लेकिन DAG/task semantics के लिए acceptable है।
  • Observability/UX Celery/Temporal की तुलना में major selling point है: workflows, worker health, और DAG execution inspect करने के लिए UI; argument visibility और type/serialization introspection अभी बेहतर की जा रही है।

Overall reception

  • कई commenters उत्साहित हैं, कहते हैं कि वे अच्छे observability के साथ Postgres-backed, multi-language queue का इंतजार कर रहे थे।
  • Skeptics added complexity पर सवाल उठाते हैं, simple PG queues, RabbitMQ, या existing workflow engines की तुलना में, और edge cases (cancellation, exactly-once semantics, long-term scheduling, तथा dependency bloat) को लेकर चिंताएँ उठाते हैं।