Design Notion

Problem Statement: Notion as a Block Workspace

Notion is a hierarchical block editor where every paragraph, database row, and embed is an addressable object inside a workspace. Interviews probe whether you treat pages as documents or as graphs of typed blocks with independent permissions, versions, and indexes. The product promise is flexible authoring (wikis, tasks, CRM-lite databases) without sacrificing collaborative latency under hundreds of concurrent editors on a single page during an all-hands.

Why this is harder than a document editor

The instinct is to model a Notion page like a Google Doc — one document, one edit stream. That breaks immediately, because a Notion page is not a document; it is a tree of independently addressable blocks, and the operations users perform are structural: indent a paragraph under a heading, drag a database row onto another page, turn a bullet list into a toggle. Each of those is a move of a subtree, not a character edit, and two people reordering the same list concurrently is a tree-conflict problem rather than a text-merge problem. On top of that, any block can carry its own permissions and can be referenced — a synced block, a relation — from another page, so the "document" is really a graph with sharing rules attached at the node level.

The failure story that frames the design

Picture an admin who drags a shared project page under a private folder. If permission resolution is cached naively, a guest who had access a second ago keeps seeing the page — a cross-tenant leak that is far worse than a lost keystroke. So the design treats every mutation as an idempotent, auditable block operation scoped to a workspace_id, sequences those operations on a durable log before any side effect, and invalidates the permission cache along the moved subtree before acknowledging the move. The governing rule throughout: what may degrade under load is presence, formula recompute, and search freshness; what may never break is the durable op append and tenant isolation.