Glossary

Terms as they are used on this site. Workflow automation borrows vocabulary from several traditions — message queueing, business process management, distributed databases, factory operations — and a good many words arrived carrying more than one meaning. Where that is true, the entry says so instead of picking a winner.

Activity

In durable execution engines, a unit of work with a side effect, invoked by a workflow and recorded in its history. The distinction from the workflow itself matters: activities may do non-deterministic things, workflows may not. Some tools call the same concept a step, a task or an action, which is a frequent source of confusion when reading across vendors.

At-least-once delivery

A guarantee that every message will be delivered, with duplicates possible. The default in most practical systems, and the reason idempotency is not optional.

Backoff

Increasing the delay between successive retry attempts, usually multiplicatively. Reduces load on a struggling dependency. Nearly always wants random jitter added, or clients that failed together will retry together.

Backpressure

A mechanism by which a slow consumer causes producers to slow down, rather than letting an unbounded buffer absorb the difference. The alternative to backpressure is not “no backpressure” but “backpressure applied later, by exhaustion”.

Choreography

Coordination that emerges from services reacting to each other’s events, with no central coordinator. Contrasted with orchestration. Easier to extend, harder to answer “what is the current state of this process” about.

Compensation

An action that attempts to undo the effect of a step that already completed. Distinct from a rollback: it adds a correcting event rather than erasing the original, and both remain visible to anyone who was watching.

Cron expression

A compact syntax for recurring schedules. Widely used and inconsistently implemented — field counts, second-level precision, day-of-week numbering and time zone handling all vary between implementations, so an expression that is correct in one system is not necessarily correct in another.

Dead-letter queue

Where messages go after repeatedly failing to be processed. Its value depends entirely on someone reading it. An unattended dead-letter queue is a list of work the system accepted and then silently dropped.

Deduplication window

The period during which a system remembers idempotency keys it has already seen. Once it expires, a repeated request is treated as new. Should be chosen against the longest realistic retry or replay delay, not against storage cost.

Determinism

The property that replaying the same workflow code against the same recorded history produces the same decisions. Required by engines that recover by replay, and the reason such engines forbid reading the clock or generating random values directly inside workflow code.

Durable execution

An execution model where a program’s progress — not just its data — is persisted, so it can survive process death and resume mid-way. Sometimes used more loosely to mean any workflow engine with persistent state, which blurs a distinction worth keeping.

Exactly-once

Often claimed, rarely meaning what a reader assumes. No system can guarantee a side effect on a remote party happens exactly once. What is achievable is at-least-once delivery combined with idempotent processing, producing an effect that is observed once. Treat the phrase as shorthand for that, and check what a given vendor means by it.

Fan-out / fan-in

Splitting one unit of work into many parallel units, then collecting their results once all have finished. The fan-in is the difficult half: it requires durable tracking of which children have completed and a policy for children that never do.

Human-in-the-loop

A step where a person supplies a decision the system cannot. A step in the workflow with a timeout and a fallback, not a gap in it.

Idempotency

The property that performing an operation more than once leaves the world in the same state as performing it once. A property of the effect, not of the code. Note that “idempotent” is often used loosely to mean “read-only”, which is a different and weaker claim.

Idempotency key

A caller-supplied identifier that lets a receiver recognise a repeated request as the same request. Must be derived from something stable across attempts, which rules out timestamps and values generated fresh on each send.

Job

Depending on the tradition, a single unit of queued work, a scheduled recurring program, or a whole batch run. In field service and manufacturing it means something different again — the customer-facing piece of work. Worth disambiguating early in any conversation that spans two of those worlds.

Lease

A time-limited claim on a work item, held by one worker so others do not take it. Expires so that a worker dying does not strand the item permanently. Also called a visibility timeout, an ack deadline or a lock, depending on the system.

Orchestration

Coordination directed by a central component that knows the whole process and tells each participant what to do. Contrasted with choreography. In some industrial and cloud contexts the same word means resource provisioning, which is unrelated.

Poison message

An item that fails every time it is processed, usually because of its own content rather than a transient condition. Without a retry limit it consumes capacity indefinitely; with one it ends up in the dead-letter queue.

Reconciliation loop

Periodic work that compares intended state with actual state and re-enqueues anything that has fallen behind. Converts lost events into late events, which is the difference between a system that is occasionally slow and one that is occasionally wrong.

Replay

Re-running recorded work. In durable execution it means reconstructing a workflow’s state by re-executing its code against its history — an internal mechanism. In queueing it means re-delivering messages from a store, usually a deliberate operator action. The two meanings are unrelated and frequently collide in the same conversation.

Retry budget

A cap on retries expressed as a share of total traffic rather than per request. Prevents the case where every client independently obeys its own limit and their combined retries overwhelm a recovering dependency.

Saga

A sequence of local transactions across separate systems, each with a compensating action, used where no distributed transaction is available. The academic definition is stricter than common usage, which now covers most multi-step processes with an unwind path.

Scheduler

The component deciding when work starts, on the basis of time. Distinct from a queue, which decides what work is available on the basis of demand. Confusingly, the same word describes the component assigning work to workers in some frameworks, and the person building technician rotas in field service software.

Staleness

Time since a piece of work last completed successfully. The most useful single health metric for background processing, because it detects work that stopped happening — which run counts and error rates cannot.

Task

The most overloaded word in this vocabulary. It means a queued unit of work, an item on a person’s list, an assignment given to a machine, and a line on a project plan — sometimes in the same product. Almost always worth qualifying.

Timer

A durable record that an instance should become runnable at a future moment. The long-lived equivalent of a sleep, and the reason a workflow can wait a month across several deployments without losing its place.

Worker

A process that takes items from a queue and executes them. Scales independently of whatever produces the work, which is the main structural benefit of putting a queue between them.

Workflow

A defined sequence of steps with control flow, state and a lifecycle. Used both for the definition and for a particular running instance of it; where the difference matters, these essays say definition or instance.