What is the main invariant for local-first full-text search?

Every visible result belongs to one committed local index revision and one query generation. Partial builds and replies from older generations never replace the current result set.

Should indexing run on the main browser thread?

No. Tokenization, segment construction, compaction, and most queries should run in a worker. The main thread owns input, focus, URL state, progress, and bounded result rendering.

How should incremental updates work?

Append document mutations to a journal, build replacement segments in the worker, preserve the previous committed manifest, and atomically publish a new manifest only after validation.

What should happen when browser storage is full?

Keep the last committed index usable, stop accepting unsafe writes, explain the required and available space, offer scoped cleanup or corpus reduction, and never pretend persistence succeeded.

How do you keep memory bounded?

Persist durable segments, load only dictionaries and hot posting blocks, cap candidate heaps and snippet windows, transfer compact buffers, and release data by explicit lease.

Can a local index be treated as the source of truth?

It is authoritative for offline search over its declared corpus revision, but not necessarily for remote collaboration state. The UI must expose synchronization and indexing freshness separately.

FSD-051Frontend system design Premium

Design a Local-First Full-Text Search UI

Design offline browser search with worker-owned indexing, incremental revisions, bounded memory, and honest storage states.

4 September 2026Advanced 66 min read

A local search index is a pocket observatory: the sky remains searchable when the network horizon goes dark, but every visible star still belongs to a named catalog revision.

The interview is not merely “put a search library in a worker.” It is about making browser storage, indexing cost, query ordering, incremental replacement, and offline truth visible in a calm UI.

Clarify what local-first means for this product

Ask how documents arrive, whether users edit them locally, how many files and bytes are expected, which languages and file types matter, whether multiple tabs may be open, and what “fresh” means while disconnected. Define phrase, prefix, fuzzy, field, and filter support; snippet quality; persistence expectations; import and sync behavior; and acceptable first-build time.

Measure time to first usable index, incremental indexing lag, query latency, peak worker memory, durable bytes, quota failures, stale-generation drops, corruption recovery, and the percentage of sessions that can search immediately after reload.

The public interview prompt

Design a browser-based full-text search interface for a local document collection. Search should remain useful offline and survive reload when browser storage permits.

Explain:

document identity, revisions, parsing, tokenization, term dictionaries, postings, snippets, and ranking;
worker ownership, message envelopes, cancellation, query generations, and transferable data;
initial build, incremental updates, deletions, compaction, schema migration, and atomic publication;
IndexedDB or OPFS persistence, quota estimation, eviction, corruption, and recovery;
bounded memory, hot caches, result virtualization, keyboard behavior, and accessible progress;
multi-tab coordination, sync freshness, privacy, telemetry, testing, and staged rollout.

What the premium solution covers

The full solution treats the local index as a revisioned instrument. A pocket-observatory animation keeps search alive as the network disappears, an inverted-index herbarium shows token-to-posting structure, a storage core separates durable bytes from hot memory, and a revision flipbook makes atomic publication concrete. A deterministic lab connects corpus shape and update churn to build time, storage, memory, and lag.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

Detailed, beginner-friendly explanation
Production failure modes and trade-offs
Mobile-friendly architecture diagrams
Senior and staff-level interview signals

Unlock Premium

Frequently asked questions

What is the main invariant for local-first full-text search?: Every visible result belongs to one committed local index revision and one query generation. Partial builds and replies from older generations never replace the current result set.
Should indexing run on the main browser thread?: No. Tokenization, segment construction, compaction, and most queries should run in a worker. The main thread owns input, focus, URL state, progress, and bounded result rendering.
How should incremental updates work?: Append document mutations to a journal, build replacement segments in the worker, preserve the previous committed manifest, and atomically publish a new manifest only after validation.
What should happen when browser storage is full?: Keep the last committed index usable, stop accepting unsafe writes, explain the required and available space, offer scoped cleanup or corpus reduction, and never pretend persistence succeeded.
How do you keep memory bounded?: Persist durable segments, load only dictionaries and hot posting blocks, cap candidate heaps and snippet windows, transfer compact buffers, and release data by explicit lease.
Can a local index be treated as the source of truth?: It is authoritative for offline search over its declared corpus revision, but not necessarily for remote collaboration state. The UI must expose synchronization and indexing freshness separately.