Requirements

Functional Requirements:

• Enable real-time collaborative editing where multiple users can edit the same document and see each other's changes instantly.
• Support offline editing with automatic synchronization of changes when the connection is restored.
• Enable commenting on text ranges with threaded replies for asynchronous review workflows.
• Enable sharing and permission controls, allowing owners to add viewers or editors and create shareable links.
• Store a revision history of every change, allowing users to view or restore past versions.

Non-Functional Requirements:

• availability and final consistency
• scalibility

Real-time collaborative editing with eventual consistency

100K viewers, 100 editors per doc, millions of documents

1 second latency target, offline sync support

Comments, sharing, permissions

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

High-Level Design

Editor/Viewer (Browser)

↓ WebSocket

Server (routing, auth)

├── Modification Service (consistent hashing per doc)

│ ├── Applies OT transformation

│ ├── Updates Redis (snapshot)

│ ├── Writes to WAL

│ └── Publishes delta to PubSub

│

├── Viewing Service

│ ├── Subscribes to PubSub → pushes deltas to existing viewers

│ └── Fetches Redis snapshot → sends to new viewers

│

├── Comment Service → PubSub

├── Notification Service → PubSub (@ mentions)

└── Storage Bucket (attachments, periodic snapshots)

Redis → latest snapshot + recent deltas

WAL → every operation, source of truth

Database → metadata, permissions, periodic snapshots

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.