Why access IndexedDB exclusively from a Web Worker?

WHAT THIS TESTS: This question probes your understanding of browser threading models, the real-world cost of asynchronous APIs on the main thread, and distributed-systems-lite concerns inside a single browser tab. The interviewer wants to see if you treat the main thread as a scarce resource and if you understand that moving work off-thread introduces coordination costs, not just benefits.

A GOOD ANSWER COVERS four things in order. First, state that the Web Workers API explicitly exposes IndexedDB inside workers, so storage logic can run entirely off the main thread. This prevents IndexedDB serialization, deserialization, and transaction callback overhead from competing with frame rendering and input handling. Second, quantify the main thread benefit: even though IndexedDB is asynchronous, large object serialization or bulk reads can still cause jank at 60fps because the work runs on the main thread event loop. Third, detail the communication cost. postMessage uses the Structured Clone Algorithm, which copies data rather than sharing it; for multi-megabyte payloads this adds latency and memory pressure. Fourth, explain synchronization patterns. The UI and worker need a request-response protocol, often promise-based, where the worker acts as a storage backend. Mention handling out-of-order responses, request IDs, and potential for backpressure if the UI posts messages faster than the worker can commit to IndexedDB.

COMMON WRONG ANSWERS: Claiming that workers and the main thread share memory directly. They do not; data is copied via Structured Clone unless you use Transferable Objects or SharedArrayBuffer. Saying IndexedDB is synchronous and therefore must move to a worker; it is asynchronous, but async work still consumes main thread CPU. Ignoring the overhead of postMessage entirely, as if offloading is free. Proposing DOM manipulation inside the worker, which is impossible.

LIKELY FOLLOW-UPS: How would you handle a write in the worker while the user edits the same record in the UI? When would Transferable Objects or SharedArrayBuffer be worth the complexity? How do you debug race conditions between tabs using IndexedDB plus a worker? What is the memory cost of keeping large query results in the worker versus shipping them to the main thread?

ONE CONCRETE EXAMPLE: In a photo management app, thumbnail metadata lives in IndexedDB. The main thread sends a message like { id: 42, op: getRange, start: 0, count: 100 } to the worker. The worker queries IndexedDB, sorts and filters off-thread, then posts back a compact array of metadata objects. The UI remains at 60fps during the fetch because serialization and IDB transaction callbacks run in the worker. The complexity appears when the user deletes a photo on the UI before the worker finishes loading the range; the app must cancel or ignore stale responses using request correlation IDs.

Source: developer.mozilla.org