Show HN: Hatchet – fila de tarefas distribuída de código aberto

Modelo de arquitetura e durabilidade

• As tarefas são sustentadas por workflows predefinidos cujas etapas e entradas/saídas são persistidas no Postgres.
• Os componentes do engine fazem polling no Postgres, atribuem trabalho por conexões gRPC de longa duração e acompanham timeouts e retries no banco de dados.
• A execução durável é “pelo menos uma vez”: as etapas podem ser reproduzidas com entradas armazenadas; recomenda-se projetar tarefas idempotentes.
• Não há necessidade de locks baseados em Redis; o Postgres é a camada central de durabilidade e coordenação.

Comportamento dos workers e semântica de falhas

• Os workers enviam heartbeat a cada poucos segundos; se ficarem inativos por ~60s, as tarefas são reatribuídas (se ainda houver retries).
• Sinais de cancelamento são enviados, mas não há garantia de entrega; execuções duplicadas são possíveis se workers ignorarem cancelamentos ou retornarem após a reatribuição.
• Isso é reconhecido como um caso de borda que precisa de alertas e melhor monitoramento.

Workflows, DAGs e limitações

• Os workflows são declarados como DAGs antecipadamente; isso simplifica visualização, versionamento e depuração de múltiplas etapas em comparação com código procedural.
• Trade-offs: ainda não há try/catch dentro de uma única tarefa, nem um modelo simples de “await futures & gather later”. Workflows procedurais estão no roadmap.
• Child workflows podem ser disparados a partir de etapas; está sendo considerada a dispersão (fan-out) com base em um valor de retorno em array.
• A mutação dinâmica do DAG em tempo de execução não é descrita atualmente como suportada.

Comparações com outras ferramentas

• Posicionado como uma alternativa a Celery/Redis/RabbitMQ com observabilidade mais forte e uma UI, e conceitualmente semelhante a Temporal/Cadence, mas mais simples de operar.
• Diferencia-se de pg-boss/River/Graphile Worker por ser um serviço separado + UI, em vez de uma biblioteca pura, e por adicionar semântica de workflow e pools de workers.
• Comparado a Windmill/Inngest: mecanismo de workflow semelhante baseado em Postgres; Hatchet é mais estreito (fila de tarefas + workflows) e licenciado sob MIT.

Dependências e escolhas de infraestrutura

• Hoje usa Postgres mais RabbitMQ para parte de pub/sub; os mantenedores gostariam de migrar para Postgres LISTEN/NOTIFY ou algo semelhante, mas observam complicações com poolers de conexão e replay.
• Algumas pessoas no thread argumentam que RabbitMQ é barato e confiável; outras preferem minimizar os componentes ao redor do Postgres.

Auto-hospedagem, cloud, preços, licenciamento

• Existe um guia de auto-hospedagem; o ponto-chave é um serviço de ingestão altamente disponível e Postgres gerenciado com PITR.
• A oferta cloud está em acesso inicial; os preços ainda não foram publicados.
• O projeto é totalmente MIT; a receita deve vir do Hatchet Cloud hospedado e possivelmente de suporte enterprise.
• Há consciência do risco de “lift-and-serve” dos hyperscalers; eles escolhem MIT apesar disso.

Agendamento, jobs adiados e casos de uso

• O agendamento baseado em cron existe via uma biblioteca cron em Go; o agendamento único/adiado existe em forma básica e está sendo refatorado para ser orientado a banco de dados e escalável.
• Alguns casos de uso de lembretes/notificações de longo prazo (por exemplo, follow-ups de saúde) ainda não são bem suportados, mas são um alvo.
• Hatchet não é específico para IA, mas é apresentado como adequado para pipelines de GenAI e outros workflows multi-etapas e limitados por recursos.

Desempenho e observabilidade

• Latência média de início reportada: ~50 ms para a primeira etapa, ~25 ms para etapas subsequentes em testes de carga, reconhecida como mais lenta do que filas de mensagens brutas, mas aceitável para semântica de DAG/tarefa.
• Observabilidade/UX é um grande diferencial em relação a Celery/Temporal: UI para inspecionar workflows, saúde dos workers e execução do DAG; ainda está melhorando a visibilidade de argumentos e a introspecção de tipos/serialização.

Recepção geral

• Muitos comentaristas estão entusiasmados, dizendo que esperavam por uma fila multi-language com boa observabilidade baseada em Postgres.
• Céticos questionam a complexidade adicional em relação a filas PG mais simples, RabbitMQ ou engines de workflow existentes, e levantam preocupações sobre casos de borda (cancelamento, semântica exactly-once, agendamento de longo prazo e inchaço de dependências).