Workflow Engine English: Inngest and Temporal Vocabulary
Learn the English vocabulary of durable workflow engines — Inngest and Temporal — including retry policy, idempotency, fan-out, and compensating transactions.
Introduction
Workflow engines like Inngest and Temporal solve one of the hardest problems in distributed systems: making sure a multi-step process completes reliably even when servers crash, networks fail, or third-party APIs time out. These tools come with a precise vocabulary that engineers must understand to design and discuss reliable systems. For non-native English speakers, learning this vocabulary is essential — many of these terms appear in technical interviews, architecture discussions, and documentation every day.
Durable Execution
The most important concept in both Inngest and Temporal is durable execution. A durable function is one whose progress is automatically saved so that if the process crashes, execution can resume from where it stopped rather than starting over. You might say: “We switched to a durable function for the payment flow because a server restart was causing orders to be lost.”
Workflow replay is the mechanism that makes this possible. When a workflow resumes after a failure, the engine replays the history of past events to reconstruct the in-memory state. “Because Temporal uses workflow replay, you must write deterministic code — avoid using random numbers or the current date directly inside a workflow.”
A workflow step (called an activity in Temporal) is a single unit of work within a larger workflow — for example, sending an email or charging a credit card. Steps are the building blocks that the engine tracks individually. “We broke the onboarding workflow into five steps so that each one can be retried independently.”
Event Triggers and Retry Policy
An event trigger is the signal that starts a workflow. In Inngest, you send an event with a name and payload; any function subscribed to that event name will run. “The order.created event trigger kicks off three separate workflows in parallel: inventory check, payment capture, and email confirmation.”
A retry policy defines what the engine should do when a step fails. It specifies how many times to retry and how long to wait between attempts. Retry backoff is the strategy of waiting longer between each successive retry — for example, 1 second, then 2 seconds, then 4 seconds. “Set an exponential retry backoff so that a struggling third-party API is not overwhelmed with immediate retries.”
Idempotency
Idempotency means that running the same operation multiple times produces the same result as running it once. An idempotent step can be safely retried without causing duplicate effects — for example, charging a customer twice. “Always make your payment step idempotent by checking whether a charge already exists before creating a new one.”
Non-idempotent operations are dangerous in workflow systems because retries are automatic. Engineers say: “That API endpoint is not idempotent, so we need to generate a unique idempotency key on our side before calling it.”
Fan-Out and Compensating Transactions
Fan-out describes a pattern where one workflow step triggers many parallel child tasks. “After a user uploads a video, the processing workflow fans out into ten parallel transcoding jobs, one for each resolution.” The opposite — collecting results from parallel tasks — is sometimes called fan-in.
A compensating transaction (also called a saga) is a step that undoes the work of a previous step when something goes wrong. If you cannot roll back a database transaction directly, you write a compensation: “If the payment succeeds but the inventory reservation fails, the compensating transaction refunds the charge automatically.” This pattern is fundamental to keeping distributed systems consistent.
Key Vocabulary
| Term | Definition |
|---|---|
| durable function | A function whose progress is persisted so it can resume after a crash |
| event trigger | An event that starts or resumes a workflow |
| retry policy | Rules defining how many times and how often to retry a failed step |
| retry backoff | A strategy of waiting progressively longer between retries |
| idempotent step | A step that can be executed multiple times without duplicate side effects |
| workflow replay | Reconstructing workflow state by replaying its event history |
| fan-out | Spawning many parallel tasks from a single workflow step |
| compensating transaction | An action that reverses the effect of a previous step when recovery is needed |
Practice Tips
-
Use the word “durable” deliberately. In English, “durable” means something that lasts over time despite stress. When describing workflow engines, practice saying: “Temporal provides durable execution guarantees” rather than simply “it saves progress.”
-
Distinguish “retry” from “replay”. Retry means running a failed step again. Replay means reconstructing state from history. These are different actions. Using the correct term in code reviews will show precision and build trust with teammates.
-
Practice the fan-out pattern in writing. Write a one-paragraph description of a fan-out workflow in your domain — for example, sending notifications to thousands of users. Use the vocabulary from this post and ask a native-speaker colleague to review your phrasing.
-
Learn the prepositions. We say “subscribe to an event”, “retry on failure”, “compensate for a failed step”, and “fan out into parallel tasks.” These prepositions are fixed expressions — memorise them as complete phrases.
Conclusion
Workflow engines introduce vocabulary that sits at the intersection of distributed systems and software reliability engineering. Terms like durable function, retry backoff, idempotent step, and compensating transaction describe precise engineering decisions with real consequences for system correctness. Master this language and you will be able to contribute confidently to architecture reviews, write clear documentation, and ask the right questions when something goes wrong in production.