Hatchet – cola de trabajos distribuida de código abierto

Cola de trabajos distribuida y tolerante a fallos

• Hatchet permite diseñar cargas de trabajo duraderas que reemplazan colas o sistemas pub/sub existentes difíciles de administrar, recuperándose de fallas y resolviendo problemas como concurrencia, equidad y limitación de velocidad.
• En lugar de administrar tu propia cola de trabajos o sistema pub/sub, puedes usar Hatchet para distribuir funciones entre una serie de workers con una configuración o infraestructura mínimas.

Ventajas de Hatchet

• Programación de latencia ultrabaja y alto rendimiento
  • Hatchet está construido sobre una cola de baja latencia con un tiempo promedio de inicio de 25ms, ofreciendo un equilibrio ideal entre capacidad de interacción en tiempo real y la confiabilidad necesaria para tareas críticas.
• Concurrencia, equidad y limitación de velocidad
  • Implementa estrategias como FIFO, LIFO, Round Robin y Priority Queues con estrategias integradas de Hatchet, evitando problemas comunes de escalado con una configuración mínima.
• Resiliencia por diseño
  • Con políticas de reintento personalizadas y manejo de errores integrado, Hatchet garantiza que los trabajos puedan recuperarse rápidamente de fallas temporales.

Mayor visibilidad y control

• Observabilidad
  • Todas las ejecuciones son completamente buscables, lo que permite identificar problemas rápidamente.
• Ejecución duradera (práctica)
  • Puedes reproducir eventos y reiniciar manualmente ejecuciones desde pasos específicos del flujo de trabajo.
• Cron
  • Permite programar ejecuciones de funciones de forma repetitiva.
• Programación de una sola vez
  • Permite programar la ejecución de funciones para una hora y fecha específicas.
• Protección contra picos
  • Mitiga aumentos repentinos de tráfico y ejecuta solo lo que el sistema puede manejar.
• Streaming incremental
  • Puedes suscribirte a actualizaciones según el progreso de los workers en segundo plano.

Casos de uso de ejemplo

• Equidad para IA generativa
  • Puedes usar Hatchet para distribuir solicitudes de manera justa entre workers y evitar que usuarios muy activos saturen el sistema.
• Procesamiento por lotes para indexación de documentos
  • Hatchet puede manejar procesamiento masivo por lotes de documentos, imágenes y otros datos, y reanudar el trabajo desde la mitad en caso de fallo.
• Orquestación de flujos de trabajo para sistemas multimodales
  • Hatchet puede coordinar entradas y salidas multimodales, y manejar ejecuciones completas estilo DAG.
• Exactitud para procesamiento basado en eventos
  • Puede reaccionar a eventos externos o internos del sistema y reproducir eventos automáticamente.

Inicio rápido

• Hatchet ofrece SDKs de código abierto para Python, Typescript y Go.
• Para comenzar, puedes consultar la documentación de Hatchet o revisar el repositorio de inicio rápido.

Repositorios de SDK

• Hatchet ofrece por defecto un SDK en Go.
• También está disponible un SDK de Typescript.
• Si surge algún problema relacionado con los SDK, puedes enviar un issue en el repositorio correspondiente.

¿Existe una versión administrada en la nube de Hatchet?

• Sí, durante el período beta están ofreciendo una versión en la nube a algunas empresas que ayudan a construir y dar forma al producto.

¿Existe una versión self-hosted de Hatchet?

• Sí, en la documentación puedes encontrar instrucciones para contenedores Docker de código abierto para self-hosting.

¿Cómo se compara con las alternativas? (Celery, BullMQ)

• ¿Por qué crear otra cola administrada?
  • Querían especialmente obtener los beneficios del encolado transaccional completo, en particular para ejecuciones estilo DAG, y creen firmemente que Postgres puede reemplazar la mayoría de los casos de uso de colas.
  • Muchas colas están basadas en Redis y, si no se tiene cuidado, pueden producirse pérdidas de datos por OOM, pero al usar PG estos problemas pueden evitarse.

Problemas

• Puedes reportar bugs encontrados mediante GitHub Issues.
• Como el proyecto está en una etapa inicial, es recomendable contactarlos primero en Discord antes de hacer solicitudes de funciones complejas.

Si quieres contribuir

• Consulta la documentación de contribución y avisa en el canal #contributing de Discord en qué te gustaría trabajar para ayudar a definir la dirección del proyecto y facilitar la colaboración.

Opinión de GN⁺

• Hatchet parece ser una solución que reduce la complejidad de administrar colas de trabajos en sistemas distribuidos y ofrece alta disponibilidad y tolerancia a fallos, especialmente útil para procesamiento de datos a gran escala y servicios en tiempo real.
• Frente a otros sistemas de colas usados actualmente en el mercado, la estabilidad y escalabilidad que obtiene al usar Postgres es una ventaja destacable.
• Al adoptar Hatchet, conviene considerar la compatibilidad con la infraestructura existente, la migración de datos y la capacidad técnica del equipo.
• Las funciones avanzadas de visibilidad y control que ofrece Hatchet pueden facilitar el monitoreo del rendimiento del sistema y la resolución de problemas, reduciendo la carga de trabajo de desarrolladores y equipos de operaciones.
• Como Hatchet aún está en etapa beta, se necesita una validación suficiente en términos de estabilidad y funcionalidad, así como pruebas adecuadas antes de aplicarlo a sistemas a gran escala.

[GN⁺]

Opiniones en Hacker News

• Un usuario dice que llevaba 3 años buscando un producto con una cola de trabajos basada en Postgres, workers que funcionaran en varios lenguajes y capacidades integradas de observabilidad decentes. Comenta que revisaba el mercado cada 6 meses y evaluaba alternativas, pero siempre terminaba decepcionado. Sin embargo, menciona que quería evitar dependencias adicionales como RabbitMQ, por lo que prefería una cola basada en Postgres. Actualmente usa graphile-worker, pero dice que aún hay requisitos que no cubre.
• Otro usuario señala que este producto está respaldado por Y Combinator y se pregunta si la empresa seguirá un modelo de "open core" o si buscará otra forma de monetización.
• Otro usuario menciona que le gustan las suscripciones push de los sistemas pub/sub y explica que, por ejemplo, en GCP pub/sub se puede tener un suscriptor que haga push a un endpoint HTTP en lugar de extraer eventos de la cola. Dice que esto tiene la ventaja de poder escalar con base en solicitudes HTTP usando runtimes como Cloud Run o Lambda, e incluso escalar hasta cero. Añade que configurar el autoescalado de workers puede ser más complejo, y que aunque en RabbitMQ se puede configurar el autoescalado de KEDA con base en métricas de profundidad de la cola, eso agrega complejidad. Pregunta si hay planes de soportar un modelo en el que un daemon que mantiene una conexión HTTP pueda hacer push de trabajos.
• Un usuario pide que le expliquen por qué todas las funciones reciben un contexto como argumento. Dice que siente que eso obliga a escribir mucho código boilerplate al crear funciones.
• Otro usuario comenta que le habría gustado conocer esta idea cuando implementó un sistema distribuido de procesamiento de DAG, y que le gustaría probarlo.
• Un usuario pregunta si publican los precios del servicio en la nube y si tienen planes de crear un operador de Kubernetes para la opción autohospedada. También expresa preocupación de que, al usar la licencia MIT, Amazon podría crear en el futuro un servicio Amazon Hatchet.
• Otro usuario dice que está escribiendo una cola de trabajos para un runner de tareas basado en DAG y que quiere ejecutar grafos de trabajos usando PostgreSQL, SQLite, memoria interna, etc., sin tener que preocuparse por reintentos, timeouts, recursos serializados y similares. Dice que le interesa este enfoque.
• Un usuario dice que necesita una cola de trabajos donde los clientes, como un navegador web, puedan escuchar el progreso de un trabajo hasta su finalización. Comenta que le gusta la simplicidad y accesibilidad de Deno Queue, pero que ahí tendría que implementar por su cuenta la forma de suscribirse al estado del trabajo desde el cliente. Se pregunta si eso sería posible con Postgres y confirma, a través de un enlace de la documentación, que sí lo es.
• Otro usuario menciona que en un trabajo anterior tuvo el problema de tener que programar una cantidad ilimitada de tareas. Por ejemplo, si un paciente agenda una cita para dentro de 6 meses, había que programar una serie de recordatorios durante ese periodo. Dice que empezaron insertando registros en una cola de base de datos y haciendo polling cada pocos segundos, pero que el costo de IO por ese polling no era ideal, así que querían resolverlo sin usar un sistema distribuido. Luego cambiaron a Redis, pero tuvieron problemas como la complejidad de manejar varios dispatchers, errores OOM y la necesidad de ejecutar trabajos auxiliares para mover tareas a una cola inmediata. Consideraron cambiar a PG y usar SKIP LOCKED, entre otras cosas, pero terminó cambiando de trabajo. Se pregunta si Hatchet sería adecuado para ese caso de uso.
• Finalmente, un usuario pregunta cómo se compara Hatchet con Temporal/Cadence/Conductor y si Hatchet también soporta ejecución durable.