English for Hatchet Developers

Hatchet conversations sit at the intersection of task-queue vocabulary and workflow-orchestration vocabulary, since it’s built to handle durable background jobs with retries, concurrency control, and multi-step dependencies.

Key Vocabulary

Task — a single unit of work submitted to Hatchet for asynchronous execution, picked up by an available worker and retried automatically on failure according to policy. “Don’t run this synchronously in the request handler — submit it as a task so a slow downstream call doesn’t hold the connection open.”

Worker — a running process that connects to Hatchet and executes tasks assigned to it, scaling horizontally by adding more worker instances. “We’re bottlenecked on a single worker instance — scale out to three and this queue backlog clears in minutes instead of hours.”

Workflow / step — a sequence of dependent tasks (steps) that Hatchet orchestrates in order, with each step’s output available to the ones that depend on it. “Model this as a workflow with explicit steps instead of one task doing everything — if step two fails, we want to retry just that step, not redo the whole pipeline.”

Concurrency control — Hatchet’s mechanism for limiting how many instances of a task or workflow run simultaneously, often scoped by a key like customer ID or resource type. “Add a concurrency limit keyed on customer ID — right now one customer submitting a hundred jobs at once starves everyone else’s tasks.”

Durable execution — Hatchet’s guarantee that a workflow’s progress survives worker crashes or restarts, resuming from the last completed step rather than starting over. “If the worker crashes mid-workflow, durable execution means it resumes from the last completed step on restart — we don’t reprocess steps that already succeeded.”

Common Phrases

• “Should this run as a task, or is it fast enough to stay synchronous in the request path?”
• “Are we bottlenecked on worker capacity, or is something else causing this backlog?”
• “Does this need to be a multi-step workflow, or is a single task sufficient here?”
• “Is there a concurrency limit on this, or can one customer starve everyone else’s tasks?”

Example Sentences

Explaining an architecture decision: “We moved report generation out of the request handler and into a task — it can take thirty seconds, and nothing about that should block the API response.”

Reviewing a queue backlog: “This isn’t a code problem — we just don’t have enough worker capacity for the current volume, so let’s scale workers before looking anywhere else.”

Discussing failure recovery: “Because of durable execution, when the worker restarted mid-workflow it picked up from the step that hadn’t completed yet — nothing upstream had to rerun.”

Professional Tips

• Push anything with unpredictable latency out of the request path and into a task — it’s the most common fix flagged when reviewing slow endpoints.
• Watch worker capacity as a first diagnosis step whenever a queue backlog appears — it’s often simpler than a code-level bug.
• Model multi-step processes as an explicit workflow so partial failures can retry just the failed step, not the whole pipeline.
• Recommend concurrency control scoped by customer or resource whenever a shared queue risks one heavy user starving everyone else.

Practice Exercise

1. Explain to a teammate why a slow report-generation call belongs in a task rather than the request handler.
2. Describe the difference between a single task and a multi-step workflow, and when each is appropriate.
3. Write a sentence proposing a concurrency limit to prevent one customer from starving a shared queue.