한 사용자는 Postgres를 기반으로 한 작업 큐와 다양한 언어로 작업하는 워커(worker), 그리고 적절한 내장 관찰 기능을 갖춘 제품을 3년 동안 찾고 있었다고 말함. 이 사용자는 6개월마다 시장을 확인하고 대안을 평가했지만 항상 실망했다고 함. 그러나 RabbitMQ 같은 추가 의존성은 피하고 싶어서 Postgres 기반 큐를 선호한다고 언급함. 현재는 graphile-worker를 사용하고 있지만, 여전히 충족되지 않는 요구사항이 있다고 함.
다른 사용자는 이 제품이 Y Combinator에 지원받고 있음을 지적하며, 이 회사가 "오픈 코어" 모델을 따를지 아니면 다른 수익 창출 방법을 모색할지 궁금해함.
또 다른 사용자는 pub/sub 시스템의 푸시 구독 기능을 좋아한다고 언급하며, 예를 들어 GCP pub/sub에서는 이벤트를 큐에서 끌어오는 대신 HTTP 엔드포인트로 푸시하는 구독자를 가질 수 있다고 설명함. 이 방식은 클라우드 런이나 람다와 같은 런타임을 사용하여 HTTP 요청에 기반해 스케일링하고 제로까지 스케일링할 수 있다는 장점이 있다고 함. 워커의 자동 스케일링 설정이 더 복잡할 수 있으며, RabbitMQ에서 큐 깊이 메트릭을 기반으로 KEDA 자동 스케일링을 설정할 수도 있지만, 이는 복잡성을 추가한다고 함. 사용자는 HTTP 연결을 유지하는 데몬이 작업을 푸시할 수 있는 모델을 지원할 계획이 있는지 물음.
한 사용자는 모든 함수가 컨텍스트를 인수로 받는 이유를 설명해달라고 요청함. 이는 함수를 작성할 때 많은 보일러플레이트 코드를 작성해야 한다고 느낀다고 함.
다른 사용자는 분산 DAG 처리 시스템을 구현할 때 이 아이디어가 있었다면 좋았을 것이라고 말하며, 시도해보고 싶어함.
한 사용자는 클라우드 제공 서비스의 가격을 공개하는지, 자체 호스팅 옵션에 대해 쿠버네티스 오퍼레이터를 만들 계획이 있는지 물음. 또한 MIT 라이선스를 사용함으로써 아마존이 향후 아마존 해쳇 서비스를 만들 수 있다는 우려를 표함.
또 다른 사용자는 DAG 기반 작업 러너를 위한 작업 큐를 작성하고 있으며, PostgreSQL, SQLite, 메모리 내부 등을 사용하여 작업 그래프가 재시도, 시간 초과, 직렬화된 리소스 등을 고려하지 않고 실행되도록 하고 싶어함. 이 사용자는 해당 접근 방식에 관심이 있음.
한 사용자는 클라이언트(웹 브라우저)가 작업의 진행 상황을 완료까지 들을 수 있는 작업 큐가 필요하다고 말함. Deno 큐의 단순함과 접근성을 좋아하지만, 클라이언트에서 작업 상태를 구독하는 방법을 직접 구현해야 한다고 함. Postgres 기반으로 가능할지 궁금해하며, 문서 링크를 통해 가능함을 확인함.
다른 사용자는 과거 직장에서 무제한의 작업을 스케줄링해야 하는 문제를 겪었다고 언급함. 예를 들어, 환자가 6개월 후에 예약을 잡으면, 그 기간 동안 약속을 상기시키는 일련의 알림을 스케줄링해야 함. 이 사용자는 데이터베이스 큐에 레코드를 입력하고 몇 초마다 폴링하는 방식으로 시작했지만, 폴링으로 인한 IO 비용이 이상적이지 않아 분산 시스템을 사용하지 않고 이를 해결하고자 했음. Redis로 전환했지만, 여러 디스패처를 다루는 복잡성, OOM 문제, 즉시 큐로 작업을 이동시키기 위한 보조 작업을 실행해야 하는 등의 문제가 있었음. PG로 전환하고 SKIP LOCKED 등을 사용하는 방법을 고려했지만, 직장을 옮겼음. Hatchet이 이러한 유스케이스에 적합한지 궁금해함.
마지막으로 한 사용자는 Hatchet이 Temporal/Cadence/Conductor와 어떻게 비교되는지, Hatchet도 내구성 있는 실행을 지원하는지 물음.