You are designing a JavaScript library that coalesces many small updates into one flush. How do you decide between flushing at the microtask checkpoint (queueMicrotask or Promise.resolve().then) and flushing on a fresh task, and what does each choice cost?

## Frame the decision correctly Both options coalesce: you mark work as pending, schedule one flush, and let further updates in the same window join the existing batch. What differs is *when* control returns to the runtime relative to your flush, and that single difference drives every consequence worth arguing about. - **Microtask flush** (`queueMicrotask(flush)` or `Promise.resolve().then(flush)`): the flush runs at the checkpoint after the current run-to-completion finishes and before the runtime takes another task. The whole microtask queue drains to empty first, so your flush plus anything it enqueues completes inside the current turn. - **Task flush** (scheduling a fresh task): the runtime regains control immediately after your synchronous code returns, does whatever it does between tasks, and reaches your flush later. ## Argument for the microtask flush: observational atomicity With a microtask flush, no code outside the current turn can ever see a half-updated system. The sequence "caller mutates state N times, library flushes once" is indivisible from the perspective of every event handler, every callback, and every piece of host work, because none of them run until the drain is over. That is a strong contract: consumers of your library never need to ask "is a flush pending?", and you never have to expose a `flushSync()` escape hatch for people who got caught between the two states. It is also the lowest-latency option that is still asynchronous. The batch settles at the earliest moment that is not synchronous — you paid one checkpoint, not one full turn. ## Argument against it: the turn has no budget The drain is exhaustive and cannot be pre-empted. Whatever your flush costs is added directly to the current turn, and if the flush enqueues more microtasks, those run in the same drain too. Three failure shapes follow: 1. **Cost that scales with input.** A flush that is O(pending) is fine at ten updates and pathological at a hundred thousand. The mechanism gives you no place to stop halfway. 2. **Latency you cannot see in isolation.** Your library's flush is invisible in its own micro-benchmark and shows up as a long turn in an application profile, attributed to whatever ran first in that turn. 3. **No cooperation with other libraries.** Every microtask-flushing library in the process piles into the same drain, so the tail is the sum of all of them. ## Argument for the task flush: handing control back Scheduling a task ends your involvement in the current turn. The runtime does its own work, other pending tasks run, and the flush happens later. Any work that is genuinely deferrable — persistence, analytics, recomputing a derived cache, anything the user is not waiting on — belongs here, because the cost of a slightly stale view is far lower than the cost of a stretched turn. The cost is symmetrical to the benefit. Between the update and the flush, arbitrary code runs and can observe the un-flushed state, so "read your own writes" is no longer free — you have to define whether reads see pending updates, which usually means either reading through a pending-aware accessor or exposing an explicit synchronous flush. And your flush's actual delay is decided by the runtime's scheduling, not by you. ## The questions I would actually ask before choosing 1. **Does anything outside the library read this state?** If yes, and staleness is a correctness problem rather than a cosmetic one, the microtask flush removes the whole question. 2. **Is the flush bounded and cheap?** If its cost scales with the batch and the batch is user-controlled, the microtask queue is the wrong home — you have handed callers a way to extend a turn arbitrarily. 3. **Is anyone waiting on the result?** Work on the critical path of something a user perceives argues for the checkpoint; background reconciliation argues for a task. 4. **How does it compose with itself?** If a flush can trigger more updates, a microtask flush re-enters within the same drain and needs an explicit stop condition. A task flush gives you a natural boundary between rounds. 5. **What is the failure mode of being wrong?** Wrong microtask choice degrades responsiveness under load, diffusely and hard to attribute. Wrong task choice produces visible staleness or ordering bugs, which are easier to spot and cheaper to fix. ## A defensible default Small, bounded coalescing that other code reads → flush at the microtask checkpoint, and document that reads after the current run see a settled system. Expensive, unbounded, or best-effort work → flush on a task, and give callers an explicit way to force it when they need consistency now. Hybrid designs exist — coalesce state at the checkpoint, defer the expensive derived work to a task — and are often the right answer for a library that owns both a cheap authoritative update and an expensive projection of it. What makes this a senior-plus answer is refusing to treat it as a performance micro-choice. It is a contract decision: you are choosing whether your library guarantees that nobody ever observes the intermediate state, and everything else follows from that guarantee.