Show HN: Hatchet – cola de tareas distribuida de código abierto

Modelo de arquitectura y durabilidad

• Las tareas se respaldan con workflows predefinidos cuyos pasos y entradas/salidas se persisten en Postgres.
• Los componentes del motor sondean Postgres, asignan trabajo a través de conexiones gRPC de larga duración y registran timeouts y reintentos en la base de datos.
• La ejecución duradera es “al menos una vez”: los pasos pueden reproducirse con entradas almacenadas; se recomienda diseñar tareas idempotentes.
• No hace falta usar bloqueos basados en Redis; Postgres es la capa central de durabilidad y coordinación.

Comportamiento de los workers y semántica de fallos

• Los workers envían heartbeats cada pocos segundos; si están inactivos durante ~60s, las tareas se reasignan (si quedan reintentos).
• Las señales de cancelación se envían, pero no se garantiza su entrega; pueden producirse ejecuciones duplicadas si los workers ignoran las cancelaciones o regresan después de la reasignación.
• Esto se reconoce como un caso límite que necesita alertas y mejor monitorización.

Workflows, DAGs y limitaciones

• Los workflows se declaran como DAGs por adelantado; esto simplifica la visualización, el versionado y la depuración de varios pasos frente a código procedural.
• Compromisos: no hay try/catch dentro de una sola tarea, ni todavía un modelo simple de “await futures y agrupar más tarde”. Los workflows procedurales están en la hoja de ruta.
• Los workflows hijos pueden activarse desde pasos; se está considerando un fan-out basado en un valor de retorno de tipo array.
• La mutación dinámica del DAG en tiempo de ejecución no se describe actualmente como soportada.

Comparaciones con otras herramientas

• Se posiciona como una alternativa a Celery/Redis/RabbitMQ con observabilidad más fuerte y una UI, y conceptualmente similar a Temporal/Cadence pero más fácil de operar.
• Se diferencia de pg-boss/River/Graphile Worker por ser un servicio separado + UI en lugar de una biblioteca pura, y por añadir semántica de workflows y pools de workers.
• Comparado con Windmill/Inngest: motor de workflows similar basado en Postgres; Hatchet es más acotado (cola de tareas + workflows) y tiene licencia MIT.

Dependencias y decisiones de infraestructura

• Hoy usa Postgres más RabbitMQ para parte del pub/sub; a los mantenedores les gustaría migrar a Postgres LISTEN/NOTIFY o algo similar, pero señalan complicaciones con los poolers de conexiones y la reproducción.
• Algunas personas en el hilo argumentan que RabbitMQ es barato y fiable; otras prefieren minimizar las piezas alrededor de Postgres.

Autoalojamiento, cloud, precios y licencia

• Existe una guía de autoalojamiento; lo clave es un servicio de ingestión altamente disponible y Postgres gestionado con PITR.
• La oferta cloud está en acceso anticipado; el precio aún no se ha publicado.
• El proyecto es totalmente MIT; se espera obtener ingresos de Hatchet Cloud alojado y posiblemente de soporte empresarial.
• Hay conciencia del riesgo de “lift-and-serve” de los hyperscalers; aun así, eligen MIT.

Programación, trabajos retrasados y casos de uso

• Existe programación basada en cron mediante una biblioteca de Go; la programación única/diferida existe de forma básica y se está refactorizando para que dependa de la BD y escale.
• Algunos casos de uso de recordatorios/notificaciones a largo plazo (por ejemplo, seguimientos sanitarios) todavía no están bien soportados, pero son un objetivo.
• Hatchet no es específico de IA, pero se presenta como adecuado para pipelines de GenAI y otros workflows multietapa con uso intensivo de recursos.

Rendimiento y observabilidad

• Latencia media de arranque reportada: ~50 ms para el primer paso, ~25 ms para pasos posteriores en pruebas de carga; se reconoce que es más lenta que las colas de mensajes puras, pero aceptable para semántica de DAG/tareas.
• La observabilidad/UX es un gran punto de venta frente a Celery/Temporal: UI para inspeccionar workflows, salud de workers y ejecución de DAG; aún está mejorando la visibilidad de argumentos y la introspección de tipos/serialización.

Recepción general

• Muchos comentaristas están entusiasmados y dicen que llevaban tiempo esperando una cola multiidioma respaldada por Postgres con buena observabilidad.
• Los escépticos cuestionan la complejidad añadida frente a colas PG más simples, RabbitMQ o motores de workflows existentes, y plantean preocupaciones sobre casos límite (cancelación, semántica exactamente una vez, programación a largo plazo y bloat de dependencias).