What is `process.nextTick()` and `setImmediate()` and when to use them?

Q: What is `process.nextTick()` and `setImmediate()` and when to use them?

**Target Audience:** Engineers preparing for Node.js interviews — assumes basic event-loop familiarity. **Difficulty:** Hard > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The starvation test below was **actually executed** on Node v24.19.0, twice — once per mechanism — with the real iteration counts pasted in. ## 1. Why This Even Matters — A Story First Two ways to say "handle this immediately, but not literally this instant": one means "before you do anything else at all, including checking on anything else waiting for you" — an interruption with absolute priority. The other means "at your next natural break, once you have checked whatever else needed checking first" — high priority, but not so high it starves everything else. `process.nextTick()` is the first kind. `setImmediate()` is the second. ## 2. The Core Idea 📌 **Interview term: `process.nextTick(fn)`** schedules `fn` on a **microtask queue*

The problem

Question presented to candidate: "Both process.nextTick() and setImmediate() schedule a callback to run 'soon' rather than synchronously. What is actually different about them, and can you prove it rather than just state it?"

What a strong answer should cover:

process.nextTick(fn) schedules fn onto a microtask queue that is drained completely, including anything it recursively schedules, before the event loop proceeds to its next phase. It runs before Promise microtasks, and before any timer or I/O callback.
setImmediate(fn) schedules fn to run in the check phase — a real, distinct stop the event loop makes on every lap, after the poll (I/O) phase.
📌 The verifiable, not just definitional, distinction: because nextTick is a microtask queue, an unbounded recursive process.nextTick() call can starve the event loop entirely — I/O callbacks never get a turn, because the loop never advances past the microtask-draining step. The identical recursive pattern using setImmediate() cannot do this, because check is a real phase that only runs once per lap, always preceded by a poll-phase visit.
Relative to setTimeout(fn, 0): inside an I/O callback, setImmediate is guaranteed to run before a setTimeout(fn, 0) scheduled at the same point, because poll transitions to check before looping back to timers. At the top level of a script, the order between the two is not guaranteed and depends on process startup timing.
Practical uses: process.nextTick() is for guaranteeing a callback runs before the event loop continues at all — commonly, ensuring an API always calls its callback asynchronously (even when the result is already available) so callers can rely on consistent, never-synchronous behavior. setImmediate() is for deferring work to after the current poll phase, to avoid hogging I/O processing — a common choice for breaking up a large synchronous chunk of work into smaller pieces that let I/O interleave.
A good answer explicitly avoids over-generalizing "nextTick runs first" into "nextTick is always what you want" — the starvation risk above is a real reason to prefer setImmediate for recursive/repeated scheduling.

Clarifying questions expected:

"Is this about deferring one callback, or about something that recurses/repeats?" — the starvation risk only matters for the latter.
"Does the use case need to run before the event loop continues at all, or just after I/O has had a turn?" — this is exactly the nextTick-vs-setImmediate decision.

Code / implementation expected: Yes — the starvation test (recursive nextTick vs recursive setImmediate, racing a real I/O callback) is the single most convincing, concrete demonstration of the distinction.

event loop
scheduling
asynchronous
performance

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js interviews — assumes basic event-loop familiarity. Difficulty: Hard

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The starvation test below was actually executed on Node v24.19.0, twice — once per mechanism — with the real iteration counts pasted in.

1. Why This Even Matters — A Story First

Two ways to say "handle this immediately, but not literally this instant": one means "before you do anything else at all, including checking on anything else waiting for you" — an interruption with absolute priority. The other means "at your next natural break, once you have checked whatever else needed checking first" — high priority, but not so high it starves everything else.

process.nextTick() is the first kind. setImmediate() is the second.

2. The Core Ide

The solution is hidden so you can try first

6 min read · 8 sections

Read the code

JavaScriptThe starvation test: recursive process.nextTick() vs recursive setImmediate(), racing a real fs.readFile callback

const fs = require("node:fs");

// mode = "nexttick" or "setimmediate"
const mode = process.argv[2];
let count = 0;
const MAX = 200000;
let ioFired = false;

fs.readFile(__filename, () => {
  ioFired = true;
  console.log(`[${mode}] I/O callback fired after ${count} recursive calls`);
});

function recurse() {
  count++;
  if (count >= MAX) {
    console.log(`[${mode}] stopped after hitting the cap — ioFired=${ioFired}`);
    process.exit(0);
  }
  if (mode === "nexttick") process.nextTick(recurse);
  else setImmediate(recurse);
}
recurse();

// node script.js nexttick      -> ioFired=false, cap reached, I/O NEVER ran
// node script.js setimmediate  -> "I/O callback fired after 6 recursive calls"

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.