Inngest makes it easy to build reliable background functions and multi-step workflows. These exercises cover Inngest's core concepts: durable steps, event system, sleeping, concurrency control, and how Inngest functions differ from simple serverless functions.
0 / 5 completed
1 / 5
At standup, a colleague asks what an Inngest function is at its core. What is the correct answer?
An Inngest function is a background function triggered by events. You define it with inngest.createFunction(), specifying which event triggers it. Inngest delivers the event to your function with automatic retries on failure, and you can break execution into steps for durable, resumable workflows. The function runs in your own infrastructure (serverless or server) — Inngest orchestrates delivery, retries, and scheduling.
2 / 5
During a PR review, a teammate asks what step.run does inside an Inngest function. Which answer is correct?
step.run(name, fn) creates a durable step in an Inngest function. When the step completes successfully, Inngest persists its return value. If the function fails later and is retried, completed steps are replayed instantly using cached results — the step function is not re-executed. This makes long multi-step workflows resilient to transient failures without re-running expensive operations like API calls or database writes.
3 / 5
In a design review, the team discusses step.sleep in Inngest. A junior engineer asks how it differs from JavaScript's setTimeout. What is correct?
step.sleep(duration) is a durable pause: the function suspends completely, freeing all resources (no process, thread, or connection held open). Inngest resumes execution after the specified duration, even days or weeks later. setTimeout, in contrast, keeps the Node.js process alive and is impractical for delays beyond seconds. This makes step.sleep ideal for follow-up emails, payment reminders, or any delayed workflow step.
4 / 5
An incident report shows the same Inngest function running multiple times concurrently for the same user, causing race conditions. A senior engineer asks what concurrency keys do. What is correct?
Concurrency keys in Inngest allow per-entity concurrency limits. You configure concurrency: { key: 'event.data.userId', limit: 1 }, and Inngest ensures only 1 run of that function is active at a time per unique userId. Excess runs are queued. This prevents race conditions in user-specific workflows — such as account updates or sequential email sends — without requiring distributed locks in your application code.
5 / 5
During a code review, a senior engineer asks what events are in Inngest and how they are sent. What is accurate?
Inngest events are JSON payloads with at minimum a name (e.g., 'order/placed') and a data object. You send them using the Inngest SDK: inngest.send({ name: 'order/placed', data: { orderId: 123 } }). Inngest receives the event, routes it to all functions that trigger on that event name, and stores it for replay and debugging. Events can also carry user and ts fields for attribution and timestamp.