Requirements

Functional Requirements:

1. Allow the user to view and collaborate on the same online doc
2. Real-time edit should be synced to all collaborators
3. Should have ACL for users with different levels of permission (view, edit or download)
4. Should e support different doc format (word, Excel, and Powerpoint, etc)

Non-Functional Requirements:

1. The system should scale up and support 50M DAU and 200M new docs every day. For one single doc, it should allow at most 1K users to collaborate in the same time.
2. The system should have low latency (<100ms) for syncing edits to all collaborators
3. The system should have high availability, and final consistency is enough

API Design

For the bi-directional communication between the user and the system (edit doc from user and sync update to user), we need to use WebSocket.

CreateDoc:

POST /doc {

"user_id": "123",

"create_time": datetime,

"title": "XXXX",

"format": "WORD" | "EXCEL" | "PPT".

} -> return a doc object with doc id, and save to the database

ViewDoc:

GET /doc/:doc_id -> query the database and render the doc content to users

EditDoc:

PATCH /doc {

"user_id": "123",

"doc_id": "456",

"time": datetime,

"content": "XXXXX",

} -> update doc content to the database and sync to all collaborators

Invite:

POST /invite {

"user_id": "123",

"doc_id": "456",

"time": datetime,

"invitees": [

"invitee_id": "789",

"permission": "VIEW" | "EDIT" | "DOWNLOAD",

]} -> add invitees to the ACL of the doc and also update the database

High-Level Design

Client:

1. Send requests to create, view, or edit online doc files
2. Send requests to add or change ACL permissions of the user's admin docs

API gateway:

1. Perform request validation, authentication, and rate-limiting to manage sudden traffic spikes
2. Route different requests to corresponding micro-services

Doc server:

1. Process requests to view, edit, create, or delete docs, and save to the database
2. Use webSocket to push updates to other users who is also collaborating on the same doc.

ACL server:

1. Process requests to add, change, or remove the permission of any collaborator, and save to the database
2. Perform operation validation based on the user's permission on any doc

S3 blob storage:

1. Redirect the user to upload media files to blob storage with presigned URL links, which will be saved to the database along with the doc contents.

Cache:

1. Cache frequently accessed doc content from the database and media files from S3 to reduce latency
2. Use the LRU and TTL strategies to remove stable data

Database:

1. Store user and doc data with the following database schema:

User {

"id": str, - primary key

"name": str, - index

"create_time": datetime,

"docs": List of doc ids }

Doc {

"id": str, - primary key

"title": str, - index

"content": str,

"create_time": datetime,

"media_links": [] of S3 link to media files

"ACL": [{

"user_id": str,

"permission": "VIEW" | "EDIT" | "DOWNLOAD",

}]}

With 200M doc per day, the total database storage is 200M * 5MB * 365 * 3 = 1000PB in 3 years.

Detailed Component Design