30% offEnding soon
FSD-050Frontend system design Premium

Design an Enterprise Knowledge Search

Design permission-aware search across company wikis, files, tickets, and messages with honest freshness, provenance, and safe previews.

Advanced 68 min read

Enterprise search is a permissioned reading room. It borrows evidence from systems it does not own, keeps every result attached to its source and revision, and verifies that the current reader may still open it.

A company wiki, cloud drive, ticket system, and chat archive do not share one identity model, one freshness clock, or one ranking scale. Putting their text into the same list is the easy part. The hard part is making that list useful without leaking a title, excerpt, author, or existence through a stale permission copy.

The frontend therefore needs an evidence contract before it needs a polished search box.

Clarify the knowledge boundary before drawing the architecture

Ask which sources are searchable, whether the product indexes content or calls sources live, how quickly edits and permission revocations must appear, and whether titles themselves are sensitive. Define supported filters, result types, preview depth, source-opening behavior, ranking stability, audit requirements, and the meaning of “all sources searched.”

Measure first permission-filtered evidence, completed-source coverage, stale-access withdrawals, preview authorization time, result usefulness, keyboard travel, cache isolation, and connector failure. A single search-latency percentile cannot describe a federation.

The public interview prompt

Design a browser-based enterprise knowledge search that retrieves documents, wiki pages, tickets, and messages from several company systems.

Explain:

  • draft and committed query state, filters, URL history, suggestions, and cancellation;
  • tenant, principal, group projection, item ACL, connector, index, and preview boundaries;
  • indexed retrieval, live federation, schema normalization, deduplication, ranking, and pagination;
  • source identity, source revision, provenance, freshness, and partial-source coverage;
  • revocation, source outages, throttling, stale snippets, missing previews, and retries;
  • keyboard and screen-reader behavior, status messages, safe excerpts, and source navigation;
  • caching, privacy, telemetry, performance budgets, testing, and staged rollout.

What the premium solution covers

The full solution stages federation as a permissioned research library. A reading-room animation routes one query into source alcoves, a permission aperture separates discoverability from preview access, a wall of source clocks makes freshness disagreement visible, and an evidence folio shows how normalization preserves provenance. A deterministic lab connects source fan-out, group expansion, excerpt size, connector delay, and ACL age to user-visible pressure.

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 enterprise knowledge search?
Every visible hit is bound to the current tenant, principal projection, query generation, source identity, source revision, and access verdict. Preview and open actions reauthorize current access.
Should enterprise search use one central index or query every source live?
Most products need a hybrid. A central index gives predictable retrieval and ranking, while selected live calls improve freshness or cover sources that cannot be fully indexed. The UI must disclose source coverage and delay.
Can indexed ACLs be trusted for previews?
Indexed ACLs can filter candidates, but a preview should be authorized against a sufficiently current policy projection or the source itself. If access cannot be verified, withhold the preview.
How should results from different sources be ranked together?
Normalize source scores into comparable features, keep source priors explicit, preserve stable evidence identity, and avoid moving the focused result as late sources arrive. Relevance never overrides authorization.
How should freshness be shown?
Treat freshness as several clocks: source modification, connector observation, index update, and access verification. Show source-specific wording instead of one misleading global green dot.
What belongs in a normalized result card?
Stable source identity, source revision, title, bounded text excerpt, source type, author and time metadata, highlights as ranges, access and freshness metadata, and an explicit preview capability.