30% offEnding soon
FSD-052Frontend system design Premium

Design a Documentation Site

Design versioned, multilingual documentation with edition-safe search, tested code samples, durable links, and explicit offline packs.

Advanced 63 min read

A documentation site is a living field guide. Readers may change the binding, language sheet, or travel pack, but the bookmark must still point to the same concept.

The interview is not only about rendering Markdown. It is about content identity, stable URLs, edition-safe search, tested examples, internationalization, offline delivery, release coordination, and a reading surface that remains dependable during constant product change.

Clarify the publishing contract

Ask who authors content, which product versions remain supported, how translations are produced, whether code can execute in the browser, how often pages change, how large the corpus is, which pages need offline access, and what search freshness readers expect after a deploy.

Measure successful search-to-page navigation, zero-result rate by version and locale, stale-link rate, anchor survival, code-copy success, example test failures, translation coverage, offline-pack completion, cache mismatch recovery, Core Web Vitals, accessibility defects, and rollback time.

The public interview prompt

Design a documentation website for a developer platform. It must support multiple product versions and languages, fast full-text search, syntax-highlighted code samples, stable deep links, SEO, and optional offline reading.

Explain:

  • canonical content identity, versioned and localized routes, redirects, durable headings, and URL history;
  • authoring, validation, translation, code-sample testing, build manifests, publication, and rollback;
  • static or server rendering, navigation hydration, search indexing, result ranking, and edition filtering;
  • code tabs, copy and run behavior, wrapping, focus, annotations, and accessible language changes;
  • service-worker lifecycle, explicit offline packs, cache budgets, freshness, quota, and deletion;
  • analytics, privacy, abuse controls, performance budgets, observability, testing, and staged rollout.

What the premium solution covers

The complete solution treats documentation as immutable editions connected by a durable concept graph. A field-guide binder animation makes version, locale, search, and offline identity visible. A translator's type case, executable-sample flight case, and offline expedition satchel explain the hardest subsystems without repeating the visual forms used by neighboring guides. A deterministic lab turns corpus shape and release cadence into build, search, and cache budgets.

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 core invariant of a documentation site?
Every page, search hit, code sample, anchor, and offline record must name the same immutable content edition. Deploys add editions instead of mutating existing meaning.
Should version and locale be stored only in a cookie?
No. Put both in shareable URLs. Preferences can choose a destination, but copied links, history entries, search results, and crawlers need an explicit edition.
How should documentation search handle product versions?
Bind the query to a version and locale before ranking, label cross-version results, and preserve the selected facet in the destination URL.
How should missing translations behave?
Render a clearly labeled fallback with the source language marked in the DOM, preserve the requested locale in navigation, and never imply that fallback content was translated.
What belongs in an offline pack?
A chosen edition manifest, selected pages, the matching search shard, essential shell assets, and required code assets. Keep size and freshness visible and avoid silently caching the entire site.
How are trustworthy code samples published?
Treat samples as tested build artifacts with a sample revision, product version, dependency lock, runtime target, expected output, and copy behavior.