Design Wikipedia or Notion

How the interviewer opens it

“Design a wiki and document system like Wikipedia or Notion. Users should be able to create, edit, and organize pages, keep full revision history, and read pages quickly from anywhere.”

The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.

What to clarify first

• content and save semantics
• organization and access
• revision history
• scale
• read:write mix
• latency
• consistency and authorization
• durability and deletion
• geography and failures
• optional features

The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.

Scope of a strong answer

What interviewers probe

Atomic saves and trustworthy revision history

A save changes both immutable history and the mutable current-page pointer, potentially across blob storage and a database. Concurrent editors and ambiguous retries must not lose edits or create a misleading history.

Fast global reads without leaking private revisions

Immutable content is easy to cache, but the current revision and access rights change. A globally cached page must satisfy both bounded staleness and permission revocation, including for historical versions.

Page moves, stable links, and bounded tree depth

A subtree move must preserve identity, prevent cycles, and keep every descendant within the depth limit. Concurrent moves or descendant creation can invalidate checks unless validation and mutation share one serialization boundary.

Common mistakes

• Designing CRDTs or operational transformation before asking whether live collaborative typing is required.
• Treating backups or an overwritten content row as full user-visible revision history.
• Failing to make revision creation and head advancement one atomic metadata operation.
• Caching revision content safely but overlooking mutable visibility, membership, and historical-content access.
• Using paths as identity, allowing concurrent moves to create cycles, or enforcing the depth limit only on the moved root rather than its deepest descendant.
• Adding a custom sharded write platform for roughly 230 peak saves per second while ignoring revision storage growth and global read traffic.

The bar by level

Senior (L5/E5)

Connects immutable body storage to transactional metadata without dangling committed references, handles ambiguous save retries, separates head and revision caches, provides read-your-writes, and enforces authorization on cached history. Makes structural validation and updates one protected operation, preventing both cycles and excessive descendant depth, including races with page creation.

Staff (L6+/E6+)

Required core: defines end-to-end freshness and revocation bounds across cache layers, explains behavior when the authoritative region is unavailable, and preserves acknowledged saves through machine or availability-zone failure. Uses one write authority and rejects unsafe writes during partitions; automatic regional failover and fencing are not required in the baseline. Justifies serialized structural validation and its subtree-scan cost using the workload, and accounts for indefinite history growth without unnecessary write-side complexity. Follow-up expectations apply only when asked: regional write takeover requires ownership fencing and an explicit replication/durability trade-off; live collaboration requires a conflict-resolution and revision-boundary model; inherited permissions require safe access changes during moves. Do not penalize omission of unasked extensions.