Hatchet – Nền tảng điều phối tác vụ dựa trên Postgres

• Nền tảng xử lý tác vụ nền quy mô lớn mã nguồn mở dựa trên Postgres
• Hàng đợi tác vụ phân tán (Distributed Task Queue) và nền tảng điều phối workflow
• Hỗ trợ workflow tác vụ phức tạp, khôi phục sau lỗi, lập lịch, trigger theo sự kiện, đến giám sát thời gian thực
• Cung cấp SDK cho Python, Go, TypeScript
• Giấy phép MIT, cung cấp cả bản self-hosting và cloud

Tóm tắt các tính năng chính

• Quản lý hàng đợi

  • Hệ thống hàng đợi bền vững dựa trên Postgres
    • Xếp hàng theo khóa (triển khai phân phối tác vụ công bằng)
    • Giới hạn tốc độ (Rate limiting)
    • Sticky Assignment và Worker Affinity
  • Tự động xử lý phân phối tác vụ, retry và thông báo lỗi
  • Cung cấp ví dụ cho Python / TypeScript / Go

• Điều phối tác vụ

  • Xây dựng workflow dựa trên DAG
    • Thực thi theo điều kiện (ví dụ: sleep, trigger theo sự kiện, thực thi có điều kiện dựa trên giá trị đầu ra của tác vụ cha, v.v.)
    • Có thể xử lý logic phân nhánh phức tạp
  • Định nghĩa phụ thuộc giữa các tác vụ, chạy song song nhiều tác vụ
  • Hỗ trợ lưu và khôi phục kết quả trung gian bằng durable task
    • Thực thi hàm bền vững: khi lỗi xảy ra, lưu cache trạng thái trung gian và khôi phục bằng cách chạy lại
    • Cũng hỗ trợ Durable Sleep và Durable Events

• Kiểm soát luồng (Flow Control)

  • Giới hạn đồng thời theo từng người dùng
  • Giới hạn tốc độ (Rate Limiting) toàn cục và động
  • Đảm bảo tính ổn định hệ thống thông qua phân tán tác vụ có chiến lược

• Lập lịch tác vụ

  • Hỗ trợ cron job, thực thi theo lịch hẹn, durable sleep
  • Ví dụ: chạy vào nửa đêm mỗi ngày, đặt lịch tại thời điểm cụ thể, chờ đến thời gian chỉ định, v.v.

• Định tuyến tác vụ

  • Sticky Assignment: gắn tác vụ vào cùng một worker
  • Worker Affinity: áp dụng logic chọn worker tối ưu

• Trigger theo sự kiện

  • Có thể thực thi tác vụ sau khi nhận sự kiện bên ngoài
  • Có thể kết hợp điều kiện sự kiện/sleep

• Web UI thời gian thực

  • Dashboard và giám sát thời gian thực
  • Xem log tác vụ, thiết lập cảnh báo (Slack/email)

Khi nào nên dùng Hatchet?

• ✅ Khi cần xây dựng workflow dựa trên DAG
• ✅ Khi việc retry và bảo toàn trạng thái sau lỗi là quan trọng
• ✅ Khi cần phân tán xử lý tác vụ cho ứng dụng có nhiều người dùng
• ❌ Khi chỉ cần một hàng đợi đơn giản, thiết lập nhanh (khuyên dùng Celery/BullMQ, v.v.)
• ❌ Khi khả năng tích hợp với nhiều data connector là quan trọng (khuyên dùng Airflow/Prefect, v.v.)

So sánh: Hatchet vs các giải pháp khác

• Hatchet vs Temporal

  • Hatchet hỗ trợ đầy đủ queue + DAG + Durable Execution
  • Temporal được tối ưu cho Durable Execution
  • Hatchet dễ self-hosting hơn (chỉ cần Postgres)

• Hatchet vs BullMQ / Celery

  • Hatchet có sẵn lưu lịch sử tác vụ + trực quan hóa UI + điều phối tích hợp
  • BullMQ/Celery là thư viện queue nhẹ nhưng thiếu tính năng giám sát

• Hatchet vs Airflow / Prefect

  • Hatchet có thực thi tốc độ cao, độ trễ thấp, tự quản lý worker
  • Airflow/Prefect tập trung vào data pipeline và mạnh về connector tích hợp

Tóm tắt

• Hatchet là nền tảng xử lý tác vụ phân tán hiện đại chạy chỉ với Postgres
• Có thể triển khai một hệ thống tác vụ Durable, Observable, Composable bằng một công cụ duy nhất
• Hỗ trợ cả cloud/self-hosting và dễ tích hợp bằng Python/Go/TypeScript

[halfenif]

Đã thử nghiệm trong 2 giờ rồi viết nhận xét này.

• Vì đang xây dựng MQ nên tôi thử xem đây có phải là thứ gì đó mới mẻ dựa trên Postgres không, nhưng hơi thất vọng khi thấy vẫn cần RabbitMQ
• Vì không nhìn từ góc độ k8s nên tôi chạy docker-compose.yaml trên podman(+Arch)
• Vì muốn dùng Postgres riêng nên phải cấu hình thêm một chút, nhưng cuối cùng dừng lại khi gặp lỗi SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER: Invalid certificate verification context
• Nếu có gì đó sai giữa chừng thì phải drop database Postgres và bắt đầu lại từ đầu
• Phải tạo API Key mỗi lần, nhưng trên giao diện web không hiển thị đầy đủ Key nên phải dùng công cụ dành cho nhà phát triển để trích xuất.

[GN⁺]

Ý kiến trên Hacker News

• Tò mò không biết điểm khác biệt là gì khi so với các trình thực thi tác vụ Python khác dựa trên pg như Procrastinate hay Chancy

• Nội dung rất thú vị

  • Khi nói rằng FOR UPDATE SKIP LOCKED không thể mở rộng đến 25k truy vấn/giây, tôi tò mò không biết đã chạm trần ở thời điểm nào
  • Tôi cũng tò mò về đọc và ghi có đệm, cũng như việc chuyển tất cả các bảng lớn sang cột ID
  • Không biết những điểm này có phải là một phần của giải pháp để mở rộng FOR UPDATE SKIP LOCKED cho phù hợp với nhu cầu hay không

• Tôi tò mò không biết các tác vụ trong hàng đợi (đưa tác vụ vào hàng đợi và đánh dấu hoàn tất) có xảy ra trong cùng một transaction với logic nghiệp vụ của tôi hay không

  • Tôi nghĩ đây là một tính năng cốt lõi của hàng đợi dựa trên cơ sở dữ liệu
  • Nó đơn giản hóa logic retry
  • Vấn đề tương tự cũng có thể xảy ra khi thực thi tác vụ
  • Đến thời điểm này thì có lẽ dùng SQS sẽ tốt hơn

• Tôi đang thiết kế một ứng dụng dựa trên event/workflow, và giải pháp này trông rất hứa hẹn

  • Tôi cũng đã cân nhắc Temporal, nhưng không cảm thấy nó thực sự phù hợp hoàn hảo
  • Giấy phép mã nguồn mở mang lại cho tôi sự tự tin về thiết kế ứng dụng
  • Tôi đã tìm kiếm các biểu thức điều kiện như CEL

• Sáu cải tiến trong kiến trúc Hatchet đã giúp hiệu năng tăng lên trên mọi phương diện

  • Phân vùng theo phạm vi cho các bảng chuỗi thời gian
  • Phân vùng theo băm cho các event tác vụ
  • Tách biệt bảng giám sát và hàng đợi
  • Đọc và ghi có đệm
  • Chuyển tất cả các bảng lớn sang cột ID
  • Sử dụng tích cực Postgres trigger
  • Đọc kỹ tài liệu hướng dẫn thì có thể làm được những điều đáng kinh ngạc

• README dường như giả định rằng có nhiều người dùng dark mode hơn

  • Logo màu trắng nên nếu không có dark mode thì sẽ không nhìn thấy
  • Xem thống kê của GitHub chắc sẽ khá thú vị

• Khi dùng Postgres làm message queue, tôi từng gặp vấn đề xử lý payload lớn (trên 50MB)

  • Giải pháp là dùng bảng unlogged và VACUUM FULL định kỳ
  • Tôi không phải chuyên gia Postgres, nhưng tò mò không biết họ đã giải quyết vấn đề này chưa

• Tôi đã xem qua tài liệu trong 15 phút rồi đưa ra phản hồi

  • Light mode, mã nguồn mở, logging và giao diện DX đều tốt
  • Có lẽ nên thay ví dụ Hello World bằng một tình huống thực tế
  • Phần code cho workflow bao gồm nhiều bước chưa trực quan lắm
  • Cần làm quen với cách tư duy, pattern và thuật ngữ của Hatchet
  • Có vẻ vẫn thiếu nỗ lực để làm cho khách hàng thấy dễ sử dụng
  • Các bài viết kỹ thuật thì có ý nghĩa, nhưng khách hàng không quan tâm đến hạ tầng đám mây
  • Vì thị trường workflow có rất nhiều lựa chọn, nên khả năng họ sẽ viết lại lần cuối hoặc pivot là khá cao
  • Nên tập trung vào hành trình tự động hóa, để mọi người có thể dễ dàng mang về và cấu hình
  • Rất khó để serialize workflow sang JSON
  • Nên giúp cho workflow của Hatchet có thể dễ dàng chuyển sang công ty khác

• Chúc mừng ra mắt v1

  • Tôi đã dùng Hatchet gần 1 năm và triển khai lên production từ 6 tháng trước
  • Hỗ trợ mã nguồn mở và phần quickstart đều rất tuyệt
  • Có thể thấy rõ lượng công sức kỹ thuật đã được đầu tư vào hệ thống

• Ấn tượng ban đầu là tốt, chúc mừng ra mắt

  • Tôi có vài câu hỏi
  • Tôi tò mò không biết có hỗ trợ tác vụ lâu dài hay không
  • Tôi tò mò không biết input và output của tác vụ được lưu ở đâu
  • Tôi tò mò không biết có thể ước tính số tác vụ mỗi giây mà hệ thống xử lý được dựa trên kích thước instance PostgreSQL và các chỉ số I/O hay không
  • Tôi đang đánh giá nhiều công cụ khác nhau và muốn biết Hatchet mang lại cảm giác thế nào
  • Tôi đang tìm một công cụ có thể làm việc với lượng boilerplate tối thiểu