Last year I got bitten by a bug that “couldn’t possibly happen”: timers were firing, yet the system behaved like they weren’t. It turned out I was using the wrong mental model of time—specifically, how an event loop processes scheduled work.

I ended up building a tiny simulator that makes “virtual time” (time advanced by the program, not by the wall clock) visible. This post is the mental model I wish I’d had earlier, plus a step-by-step code walkthrough.

## The mental model that fixed it: virtual time beats wall time

I used to think “a timeout of 10ms means the callback runs ~10ms later.” That’s a wall-clock mental model.

In an event loop, what actually matters is:

1. **There’s a queue of work** (callbacks, tasks).
2. **There are scheduled items** (timers) with target times.
3. The loop repeatedly:
   - picks the next ready item,
   - runs it,
   - and only then moves time forward to whatever it needs to run the next timer.

That means the event loop’s “time” is best understood as **virtual time**: a variable inside the runtime that jumps forward to the next scheduled deadline, rather than continuously tracking real time.

When I switched to that model, the “impossible” bug became predictable.

## A concrete failure mode: “I scheduled earlier, so it must run earlier”

Here’s the scenario I built for myself:

- I schedule two timers:
  - Timer A: fires at `t=10`
  - Timer B: fires at `t=10` as well (same deadline)
- Timer A’s callback takes a while (it blocks the loop).
- I expected Timer B to run immediately after Timer A releases the loop, still “at t=10”.

But depending on how the runtime orders same-deadline timers, Timer B might not run first—or it might run later than you’d naively expect—especially if more work gets enqueued during Timer A.

The mental model that helps: **same deadline doesn’t mean the same execution order**, and execution order affects what gets enqueued before time advances.

## The simulator: a virtual-time event loop in ~60 lines

Below is a minimal event loop simulator in Python. It’s not a full async runtime, but it’s enough to make the time behavior obvious.

```python
import heapq
from dataclasses import dataclass, field
from typing import Callable, List, Optional

@dataclass(order=True)
class Timer:
    due: int
    seq: int
    callback: Callable[[], None] = field(compare=False)

class VirtualEventLoop:
    def __init__(self):
        self.now = 0              # virtual time (jumps forward)
        self._seq = 0            # insertion order for tie-breaking
        self.timers: List[Timer] = []

    def call_later(self, delay_ms: int, callback: Callable[[], None]) -> None:
        due = self.now + delay_ms
        self._seq += 1
        heapq.heappush(self.timers, Timer(due=due, seq=self._seq, callback=callback))

    def run(self) -> None:
        while self.timers:
            # Pick the earliest due timer
            timer = heapq.heappop(self.timers)

            # Jump virtual time to that timer's due time
            if timer.due > self.now:
                self.now = timer.due

            # Run it (this may schedule more timers)
            timer.callback()

# --- Demo: observe ordering at identical deadlines ---

loop = VirtualEventLoop()

events: List[str] = []

def busy_work(name: str, duration_ms: int):
    # This simulates a callback that monopolizes the loop for "duration_ms".
    # In real runtimes, blocking code delays *everything*.
    events.append(f"{name}: start at t={loop.now}")
    loop.now += duration_ms  # advance virtual time to model blocking
    events.append(f"{name}: end at t={loop.now}")

def make_callback(name: str, delay: int, duration: int):
    def cb():
        busy_work(name, duration)
        events.append(f"{name}: done at t={loop.now}")
    return cb

# Schedule two timers with the same due time
loop.call_later(10, make_callback("A", delay=10, duration=7))
loop.call_later(10, make_callback("B", delay=10, duration=0))

loop.run()

print("\n".join(events))
```

### Walkthrough, block by block

#### `Timer` and the heap
- I model timers as `(due, seq, callback)`.
- I use `heapq` so the loop can always pick the timer with the **smallest due time**.
- `seq` is an incrementing sequence number so when two timers have the same `due`, the one scheduled first runs first. (This is a simplified tie-breaker—but it’s crucial for reproducing surprising behavior.)

#### `self.now` is virtual time
- `self.now` is not wall clock time. It’s the loop’s internal “timeline.”
- In `run()`, I jump `self.now` forward to the next timer’s `due`.

#### `busy_work` simulates blocking
- Inside Timer A’s callback, I add `duration_ms` to `loop.now`.
- This is a simplified stand-in for “the event loop is busy executing code and can’t service other callbacks.”

## What happens when I run it

With Timer A “blocking” longer, I get an output pattern like:

- A starts at `t=10`
- A ends at `t=17` (virtual time advanced by blocking)
- B then runs (but it’s no longer at `t=10` in virtual time)

That last part is the key mental model change: **even if a timer is due at `t=10`, if the loop is blocked, virtual time may advance past `t=10` before the callback gets a chance to run.**

## Why this matches real debugging pain

In real systems, the event loop is juggling:
- timers (scheduled callbacks),
- I/O readiness,
- microtasks (small “run now” jobs),
- and userland code that can block.

If you debug assuming “due time == execution time,” you’ll chase ghosts:
- logs show the timer was “scheduled for 10ms”
- but the callback appears “late”
- and ordering feels inconsistent

The virtual-time model says: execution time is a function of **when the loop becomes free** and **what’s in the queue at that moment**, not just the nominal due time.

## A subtle twist: same-deadline ordering can still matter

Even in my simplified simulator, tie-breaking uses insertion order (`seq`). Some runtimes may differ:
- they may preserve insertion order,
- or they may reorder timers based on internal bookkeeping,
- or they may group timers and flush them in batches.

That means two timers with the same due timestamp can still produce different order—and because callbacks can enqueue additional work, the differences cascade.

In mental-model terms: **“time” is only half the story; “queue semantics” decide the rest.**

## Systems thinking tie-in: what “time” controls in the whole system

Once I started thinking this way, I noticed the same pattern everywhere:

- Architecture trade-off: more concurrency can reduce blocking, but increases queue interactions.
- Incident culture: logs that only record “scheduled at” miss the real causal chain; they should also capture “executed at” and “blocked time.”
- Tech philosophy: treat the runtime scheduler as part of your system, not a black box.

This is systems thinking in miniature: the “event loop” is a component, time is a shared resource, and callbacks are processes competing for execution.

## Conclusion

I learned to debug timer and event-loop weirdness by switching mental models from “wall time” to **virtual time** plus **queue semantics**. The key insight is that a callback’s nominal due time does not guarantee its execution time—execution depends on when the loop becomes free and how same-deadline work is ordered.

A Tiny Mental Model For Debugging Event Loops With Virtual Time

I ran into a bug that looked “random” in production: a UI button sometimes didn’t update, but only when users clicked quickly. Locally it was fine. In the logs I saw the same events—same order—yet the visible result differed.

What finally unblocked me wasn’t a new framework or a bigger monitoring dashboard. It was a mental model I built: **“Time is a first-class dependency.”** More specifically: I treated the event loop’s scheduling decisions like inputs to the system and made them deterministic enough to trace.

Below is the technique I used: a tiny **deterministic time tracer** for Node.js that records when microtasks and macrotasks get queued and executed, then lets me reproduce “random” behavior by replaying the same timeline.

## The mental model: time as hidden state

In Node.js, your code runs in an event loop. Two common “lanes” matter:

- **Microtasks**: usually from `Promise` continuations (`.then`, `async/await` parts). They run *before* the event loop moves on to the next macrotask.
- **Macrotasks**: things like `setTimeout`, `setImmediate`, `setInterval` callbacks.

A common mental trap is to assume:

> “Events happen in the order I wrote them.”

But what actually happens is closer to:

> “Events happen in the order the event loop schedules microtasks/macrotasks, which depends on timing and queue state.”

That queue state is “hidden state.” My goal was to surface it.

## A minimal reproduction harness

I used a small Node.js script to simulate a “button click” that triggers both microtasks and macrotasks.

### What the script does

- Maintains a `state` counter.
- Schedules an async update (microtask).
- Schedules a timer update (macrotask).
- Records the timeline of scheduling and execution.

```javascript
// deterministic-time-tracer.js
// Run: node deterministic-time-tracer.js

'use strict';

let seq = 0;
const events = [];

function trace(type, detail) {
  events.push({
    seq: seq++,
    type,       // "queue" | "run"
    detail      // human-readable info
  });
}

function sleepMs(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function runScenario({ clickCount, jitterMs }) {
  let state = 0;

  trace('queue', `scenario:start state=${state}`);

  for (let i = 0; i < clickCount; i++) {
    const clickId = i + 1;

    trace('queue', `click:${clickId}`);

    // Microtask: promise continuation
    Promise.resolve().then(() => {
      trace('run', `microtask:click:${clickId} before state=${state}`);
      state += 1;
      trace('run', `microtask:click:${clickId} after state=${state}`);
    });

    // Macrotask: timer callback
    // Add jitter to simulate real timing differences.
    const delay = 0 + jitterMs * (clickId % 2); // either 0 or jitterMs
    setTimeout(() => {
      trace('run', `macrotask:click:${clickId} timer fired state=${state}`);
      state += 10;
      trace('run', `macrotask:click:${clickId} state=${state}`);
    }, delay);

    // Stagger clicks slightly to change scheduling behavior
    await sleepMs(1);
  }

  // Wait long enough for all timers to fire
  await sleepMs(jitterMs + 10);

  trace('queue', `scenario:end state=${state}`);
  return { state, events };
}

(async () => {
  const { state, events } = await runScenario({
    clickCount: 5,
    jitterMs: 2
  });

  console.log('final state:', state);
  console.log('--- timeline ---');
  for (const e of events) {
    console.log(`${String(e.seq).padStart(3, '0')} ${e.type.toUpperCase()} ${e.detail}`);
  }
})();
```

### What I saw when I ran it

The output alternated between `microtask` runs and `macrotask` runs in a way that wasn’t obviously tied to code order. Even when the *code* was deterministic, the *queue timing* wasn’t.

That’s the moment the mental model clicked: **the event loop is a scheduler, not a passive executor.**

## Making the hidden time explicit with a tracer + replay

The next step was turning the mental model into an engineering tool: record the “queue decisions” and replay them deterministically.

The key trick: instead of using real `setTimeout`/promises directly, I route everything through a simulated scheduler.

This doesn’t replace Node, but it gives you something powerful for debugging:

- You can reproduce a specific timeline exactly.
- You can change one knob (like microtask drain order or timer grouping) and see how outcomes shift.

### The deterministic scheduler

```javascript
// scheduler-replay.js
// Run: node scheduler-replay.js

'use strict';

function createDeterministicScheduler({ timeline, state }) {
  // timeline is an array of steps, each step tells us what should happen next
  // e.g. { kind: "micro", label: "click:1 microtask" }
  let i = 0;

  function traceRun(label) {
    state.trace.push({ step: i, label });
  }

  function runNext() {
    const step = timeline[i++];
    if (!step) throw new Error('Timeline exhausted');

    if (step.kind === 'micro') {
      traceRun(`micro:${step.label}`);
      state.value = step.delta(state.value);
    } else if (step.kind === 'macro') {
      traceRun(`macro:${step.label}`);
      state.value = step.delta(state.value);
    } else {
      throw new Error(`Unknown kind: ${step.kind}`);
    }
  }

  return { runNext };
}

// A “producer” that defines what timeline we want to simulate.
function buildTimeline({ clickCount, jitterPattern }) {
  const timeline = [];
  for (let i = 0; i < clickCount; i++) {
    const clickId = i + 1;

    // Microtask always queued per click
    timeline.push({
      kind: 'micro',
      label: `click:${clickId}`,
      delta: (v) => v + 1
    });

    // Macrotask depends on jitter pattern; we model it as a later macro step
    const jittered = jitterPattern[i % jitterPattern.length];
    if (jittered === 0) {
      // immediate macro step after micro for this model
      timeline.push({
        kind: 'macro',
        label: `click:${clickId}`,
        delta: (v) => v + 10
      });
    } else {
      // delayed macro step: interleave by placing it later in the timeline.
      // For simplicity in this toy model, we push macros after all microtasks,
      // but use jitterPattern to vary whether a macro is delayed.
      timeline.push({
        kind: 'macro',
        label: `click:${clickId}`,
        delta: (v) => v + 10
      });
    }
  }

  return timeline;
}

function runReplay(timeline) {
  const state = { value: 0, trace: [] };
  const scheduler = createDeterministicScheduler({ timeline, state });

  while (true) {
    try {
      scheduler.runNext();
    } catch {
      break;
    }
  }
  return state;
}

// Two different “time behaviors” that are hard to distinguish in real life:
const timelineA = buildTimeline({ clickCount: 5, jitterPattern: [0] }); // macro soon
const timelineB = buildTimeline({ clickCount: 5, jitterPattern: [1, 0] }); // modeled delays

const outA = runReplay(timelineA);
const outB = runReplay(timelineB);

console.log('--- replay A ---');
console.log('final value:', outA.value);
console.log(outA.trace.map(t => t.label).join('\n'));

console.log('\n--- replay B ---');
console.log('final value:', outB.value);
console.log(outB.trace.map(t => t.label).join('\n'));
```

### Why this helps

Real Node execution isn’t fully simulatable from userland, but the mental model is what matters:

- I stopped thinking “the bug is random.”
- I treated the **event loop schedule** as the real input.
- I built a tool that makes “time ordering” explicit as a timeline.

When I did that with actual code paths (UI handlers + async effects), the “random” bug turned into a consistent one: **microtasks always updated the state first, then macrotasks sometimes re-applied stale assumptions.**

## Translating the model into real fixes

Once I could see time ordering, I applied the same principle everywhere I had asynchronous state transitions:

1. **Make transitions atomic** (even if they’re split across microtasks/macrotasks).
2. **Avoid assuming “latest write wins” without defining the ordering rule.**
3. **Attach intent to updates** (e.g., sequence numbers) so late macrotasks can’t overwrite newer microtask-driven state.

Here’s a tiny example of “intent tagging” that prevents stale macrotasks from clobbering the latest state. This is the part that finally stabilized the UI behavior in my project.

```javascript
// intent-tagging.js

'use strict';

let state = {
  value: 0,
  latestIntent: 0
};

function applyMicro(intent) {
  state.value += 1;
  state.latestIntent = intent;
}

function applyMacro(intent) {
  // Guard: only apply if this macro corresponds to the latest intent
  if (intent !== state.latestIntent) return;
  state.value += 10;
}

// Simulate two quick clicks where the macrotask from click 1 fires late
async function demo() {
  state.value = 0;
  state.latestIntent = 0;

  const click1Intent = 1;
  const click2Intent = 2;

  // Click 1 schedules micro + macro
  Promise.resolve().then(() => applyMicro(click1Intent));
  setTimeout(() => applyMacro(click1Intent), 5);

  // Click 2 happens quickly
  Promise.resolve().then(() => applyMicro(click2Intent));
  setTimeout(() => applyMacro(click2Intent), 0);

  await new Promise(r => setTimeout(r, 10));
  console.log('final value:', state.value);
}

demo();
```

In this pattern, the mental model (“time is hidden state”) becomes a concrete defense: **late work must prove it’s still relevant.**

## What I learned (and what stuck)

I used to treat asynchronous behavior as “logic bugs happening out of order.” Now I treat it as **a system with a scheduler**: microtasks and macrotasks are components, and their ordering is a real dependency.

The deterministic time tracer plus replay-like thinking gave me a way to stop hand-waving about randomness. It forced me to name the hidden state (queue order) and then redesign updates so late events couldn’t overwrite newer intent.

In short: once I treated event loop scheduling as input, debugging asynchronous UI/state issues became systematic instead of mysterious.

Systems Thinking Posts

A Tiny Mental Model For Debugging Event Loops With Virtual Time

Mental Model For Debugging Event Loops With A Deterministic Time Tracer