Practice/Meta/Design DropBox

Design DropBox

System DesignMust

Problem Statement

Design a real-time collaborative note-taking system similar to Notion, Evernote, or Google Keep that allows users to create, edit, and organize notes with rich formatting capabilities. The system must support simultaneous editing by multiple users with live updates, offline capability with conflict resolution, and efficient synchronization across web, mobile, and desktop clients.

The core challenge is handling concurrent edits from multiple collaborators without losing changes or creating jarring user experiences, while also managing a flexible content model that supports rich text, embedded media, nested blocks, and organizational hierarchies. Your design should handle millions of active users creating and editing notes throughout the day, with subsecond latency for collaborative updates and the ability to scale storage for years of retained content per user.

Key Requirements

Functional

Note creation and editing -- users can create notes with rich text formatting, embedded images, links, code blocks, and nested bullet points with a WYSIWYG editor
Real-time collaboration -- multiple users can simultaneously edit the same note and see each other's changes appear live with cursor presence indicators
Organization and search -- users can organize notes into notebooks or folders, tag content, and search across all notes with substring and tag matching
Offline support -- users can read and edit notes while disconnected, with automatic synchronization and conflict resolution when reconnecting
Sharing and permissions -- users can share individual notes or entire notebooks with collaborators, controlling view-only or edit access

Non-Functional

Scalability -- support 10 million active users, with 100K concurrent editing sessions and 50TB of total note content
Reliability -- no data loss during crashes or network failures, with 99.9% uptime for note access and editing
Latency -- collaborative edits should propagate to other users within 200ms, search results within 500ms, and initial note load within 1 second
Consistency -- eventual consistency for collaborative edits is acceptable with deterministic conflict resolution, but metadata operations like permissions require strong consistency

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Operational Transformation or CRDT for Concurrent Editing

The heart of collaborative editing is letting multiple users modify the same document simultaneously without central coordination. Interviewers want to see if you understand the difference between operational transformation (OT) and conflict-free replicated data types (CRDTs), and can articulate why naive last-write-wins creates terrible user experiences.

Hints to consider:

CRDTs like Yjs or Automerge provide mathematical guarantees that concurrent operations commute, eliminating the need for a central server to serialize edits
Operational transformation requires transforming operations against concurrent ops, which is complex but works well with a central server that establishes canonical order
Character-level granularity is too chatty; most systems operate on block or paragraph boundaries with internal delta structures
Tombstones or version vectors track deletion without losing positional information needed for late-arriving concurrent inserts

2. Efficient Storage and Retrieval of Structured Content

Notes aren't just blobs of text. Modern systems support nested hierarchies of typed blocks (paragraphs, headings, code, embeds) that can be rearranged, indented, and styled. Interviewers probe whether you can model this flexibly while keeping queries fast.

Hints to consider:

A block-based model where each paragraph or element is a separate entity with parent pointers enables efficient partial updates and rendering
JSON or JSONB columns in Postgres work well for storing rich block content while maintaining queryable metadata in relational columns
Separate tables for notes (metadata), blocks (content), and versions (history) with foreign keys provide clear boundaries
Full-text search requires extracting plain text from structured blocks and indexing it separately, possibly in Elasticsearch or using Postgres GIN indexes

3. Real-Time Update Distribution and Presence

Getting edits from one user to all collaborators with low latency requires a persistent bidirectional channel. Interviewers look for understanding of WebSocket lifecycle, broadcasting patterns, and how presence awareness (who's viewing, cursor positions) differs from content synchronization.

Hints to consider:

WebSocket connections should authenticate once and maintain a session, with reconnection logic and exponential backoff for resilience
A pub/sub layer like Redis or a message bus broadcasts edits to all active sessions viewing the same note, with the server tracking which clients are subscribed to which documents
Cursor positions and selection ranges are ephemeral and sent separately from durable content changes to avoid polluting the operation log
Operational transforms or CRDT merge logic can run client-side, with the server acting as a reliable broadcast relay rather than computing transformations

4. Offline Editing and Sync Conflict Resolution

Users expect to edit notes on planes or in areas with spotty connectivity. Interviewers want to see how you queue local changes, detect conflicts when reconnecting, and merge divergent histories without losing work.

Hints to consider:

A local-first architecture where the client maintains a full copy of note content in IndexedDB or SQLite enables instant reads and writes without network
Track a vector clock or logical timestamp per client so the server can detect when incoming changes are based on stale state
Three-way merge using the last common ancestor can automatically resolve many conflicts; surface remaining conflicts in the UI for user resolution
Sync protocols like delta-sync or log shipping send only the operations since the last known server state rather than re-uploading entire documents

5. Search Indexing and Query Performance

As users accumulate thousands of notes over years, full-text search becomes critical. Interviewers probe whether you understand inverted indexes, how to keep them updated in real time, and how to scope results by permissions.

Hints to consider:

Elasticsearch or a similar search engine provides fast full-text queries with ranking, but introduces eventual consistency and operational complexity
Change data capture (CDC) from Postgres or consuming Kafka events keeps search indexes updated as notes are edited
Pre-filtering by user ownership or shared permissions before search avoids leaking private content and improves relevance
Caching frequent searches in Redis with short TTLs reduces load on the search cluster for common queries

Practice/Meta/Design DropBox

Design DropBox

System DesignMust

Problem Statement

Key Requirements

Functional

Note creation and editing -- users can create notes with rich text formatting, embedded images, links, code blocks, and nested bullet points with a WYSIWYG editor
Real-time collaboration -- multiple users can simultaneously edit the same note and see each other's changes appear live with cursor presence indicators
Organization and search -- users can organize notes into notebooks or folders, tag content, and search across all notes with substring and tag matching
Offline support -- users can read and edit notes while disconnected, with automatic synchronization and conflict resolution when reconnecting
Sharing and permissions -- users can share individual notes or entire notebooks with collaborators, controlling view-only or edit access

Non-Functional

Scalability -- support 10 million active users, with 100K concurrent editing sessions and 50TB of total note content
Reliability -- no data loss during crashes or network failures, with 99.9% uptime for note access and editing
Latency -- collaborative edits should propagate to other users within 200ms, search results within 500ms, and initial note load within 1 second
Consistency -- eventual consistency for collaborative edits is acceptable with deterministic conflict resolution, but metadata operations like permissions require strong consistency

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Operational Transformation or CRDT for Concurrent Editing

Hints to consider:

CRDTs like Yjs or Automerge provide mathematical guarantees that concurrent operations commute, eliminating the need for a central server to serialize edits
Operational transformation requires transforming operations against concurrent ops, which is complex but works well with a central server that establishes canonical order
Character-level granularity is too chatty; most systems operate on block or paragraph boundaries with internal delta structures
Tombstones or version vectors track deletion without losing positional information needed for late-arriving concurrent inserts

2. Efficient Storage and Retrieval of Structured Content

Hints to consider:

A block-based model where each paragraph or element is a separate entity with parent pointers enables efficient partial updates and rendering
JSON or JSONB columns in Postgres work well for storing rich block content while maintaining queryable metadata in relational columns
Separate tables for notes (metadata), blocks (content), and versions (history) with foreign keys provide clear boundaries
Full-text search requires extracting plain text from structured blocks and indexing it separately, possibly in Elasticsearch or using Postgres GIN indexes

3. Real-Time Update Distribution and Presence

Hints to consider:

WebSocket connections should authenticate once and maintain a session, with reconnection logic and exponential backoff for resilience
A pub/sub layer like Redis or a message bus broadcasts edits to all active sessions viewing the same note, with the server tracking which clients are subscribed to which documents
Cursor positions and selection ranges are ephemeral and sent separately from durable content changes to avoid polluting the operation log
Operational transforms or CRDT merge logic can run client-side, with the server acting as a reliable broadcast relay rather than computing transformations

4. Offline Editing and Sync Conflict Resolution

Hints to consider:

A local-first architecture where the client maintains a full copy of note content in IndexedDB or SQLite enables instant reads and writes without network
Track a vector clock or logical timestamp per client so the server can detect when incoming changes are based on stale state
Three-way merge using the last common ancestor can automatically resolve many conflicts; surface remaining conflicts in the UI for user resolution
Sync protocols like delta-sync or log shipping send only the operations since the last known server state rather than re-uploading entire documents

5. Search Indexing and Query Performance

Hints to consider:

Elasticsearch or a similar search engine provides fast full-text queries with ranking, but introduces eventual consistency and operational complexity
Change data capture (CDC) from Postgres or consuming Kafka events keeps search indexes updated as notes are edited
Pre-filtering by user ownership or shared permissions before search avoids leaking private content and improves relevance
Caching frequent searches in Redis with short TTLs reduces load on the search cluster for common queries